Code review en Rust: qué verificar y cómo dar retroalimentación en la práctica

Introducción: por qué el code review en Rust no es solo una formalidad

El code review es uno de los procesos clave en el desarrollo de cualquier software de calidad. Pero cuando se trata de Rust, este proceso adquiere una importancia especial. Rust es un lenguaje con un sistema único de propiedad (ownership) y préstamo (borrowing) que el compilador verifica en tiempo de compilación. Sin embargo, incluso si el código compila, eso no significa que esté bien escrito, sea seguro y eficiente.

En este artículo, analizaremos exactamente en qué aspectos prestar atención durante el code review de proyectos en Rust, cómo dar retroalimentación constructiva para no ofender a un colega y cómo evitar errores típicos que el compilador no detecta. El artículo está dirigido a desarrolladores que ya conocen los fundamentos de Rust, pero desean profundizar sus habilidades de revisión.

1. Seguridad de memoria y gestión de recursos

Rust garantiza la seguridad de la memoria sin un recolector de basura. Pero esto no elimina la necesidad de verificar cómo el desarrollador utiliza bloques unsafe, punteros sin procesar y llamadas FFI externas.

Qué verificar:

\n
• Uso de unsafe: cada bloque unsafe debe estar justificado y acompañado de un comentario que explique por qué es seguro. Si se puede prescindir de unsafe, es mejor hacerlo.
\n
• Fugas de recursos: verifique que todos los Box, Rc, Arc y otros punteros inteligentes se liberen correctamente. Por ejemplo, las referencias cíclicas a través de Rc sin Weak son un problema común.
\n
• Orden de Drop: si la estructura contiene campos con una implementación personalizada de Drop, asegúrese de que el orden de destrucción no provoque errores.
\n

// Ejemplo de mal código: unsafe sin comentarios\nunsafe {\n    let ptr = ...;\n    // No hay explicación de por qué esto es seguro\n    *ptr = 42;\n}\n\n// Buen código: comentario y alternativa segura\n// Usamos unsafe solo para llamar a una función C que garantiza la validez del puntero\nunsafe {\n    // El puntero se obtuvo de la API de C, que garantiza su validez durante la vida de la llamada\n    some_c_function(ptr);\n}\n

2. Modismos del código y estilo

Rust tiene sus propios modismos, que difieren de C++ o Python. El code review debe verificar qué tan bien el código se ajusta al espíritu del lenguaje.

Qué verificar:

\n
• Uso de Option y Result: evite unwrap() y expect() sin una razón explícita. En código de producción, use el manejo de errores mediante match, el operador ? o unwrap_or_else.
\n
• Pattern matching: prefiera if let y match en lugar de cadenas de is_some()/is_ok().
\n
• Uso de traits: verifique que los traits se implementen de manera significativa. Por ejemplo, la implementación de Display debe proporcionar una salida legible, no solo Debug.
\n
• Nomenclatura: en Rust se acostumbra usar snake_case para variables y funciones, CamelCase para tipos y traits. Las constantes — SCREAMING_SNAKE_CASE.
\n

// Mal: uso excesivo de unwrap\nlet value = some_option.unwrap();\n\n// Bien: manejo de errores\nlet value = match some_option {\n    Some(v) => v,\n    None => return Err("Value not found".into()),\n};\n\n// Aún mejor: con el operador ?\nlet value = some_option.ok_or("Value not found")?;\n

3. Rendimiento y asignaciones

Rust proporciona control de bajo nivel sobre la memoria, pero esto no significa que el código sea automáticamente rápido. En la revisión es importante verificar posibles cuellos de botella.

Qué verificar:

\n
• Asignaciones innecesarias: verifique si no se está creando un String o Vec