Code review en C++: qué revisar y cómo dar retroalimentación en la práctica

Code review en C++: qué revisar y cómo dar retroalimentación en la práctica

El code review no es solo una formalidad, sino una herramienta poderosa para mejorar la calidad del código. En C++, la revisión es especialmente importante debido a la complejidad del lenguaje: gestión manual de memoria, plantillas, herencia múltiple. En este artículo, analizaremos a qué prestar atención al revisar código C++ y cómo formular observaciones para que sean útiles, no ofensivas.

1. Seguridad de memoria y RAII

Lo primero que hay que verificar es la gestión de recursos. En C++ no hay recolector de basura, por lo que las fugas de memoria y la doble liberación son problemas comunes. El patrón clave es RAII (Resource Acquisition Is Initialization).

Qué revisar:

\n
• ¿Se utilizan punteros inteligentes (std::unique_ptr, std::shared_ptr) en lugar de new/delete sin procesar?
\n
• ¿Hay llamadas manuales a delete en el código? (Excepto en casos raros de trabajo de bajo nivel)
\n
• ¿Están implementadas correctamente las clases RAII: el recurso se adquiere en el constructor y se libera en el destructor?
\n
• ¿Se ha olvidado el destructor virtual en la clase base?
\n

// ❌ Malo: gestión manual\nvoid process() {\n    int* data = new int[100];\n    // ... si hay una excepción, la memoria se fuga\n    delete[] data;\n}\n\n// ✅ Bueno: RAII con std::vector\nvoid process() {\n    std::vector<int> data(100);\n    // seguro ante excepciones\n}

Cómo dar retroalimentación: En lugar de «Olvidaste liberar la memoria», diga: «Aquí es mejor usar std::vector o std::unique_ptr — esto liberará los recursos automáticamente y hará que el código sea seguro ante excepciones».

2. Const-correctness y referencias

C++ permite indicar explícitamente que los datos no deben cambiar. Esto mejora la legibilidad y permite al compilador optimizar mejor el código.

Qué revisar:

\n
• ¿Todos los parámetros que no se modifican están marcados como const?
\n
• ¿Se pasan objetos grandes por referencia constante (const T&), y no por valor?
\n
• ¿Los métodos que no modifican el objeto están marcados como const?
\n
• ¿No se usa const_cast sin una necesidad extrema?
\n

// ❌ Malo: copia de un objeto grande\nstd::string toUpper(std::string s); // copia\n\n// ✅ Bueno: referencia constante\nstd::string toUpper(const std::string& s); // sin copia\n\n// ❌ Malo: método no es const, aunque no cambia el estado\nclass Point {\n    int x, y;\npublic:\n    int getX() { return x; } // debería ser const\n};\n\n// ✅ Bueno\nint getX() const { return x; }

Cómo dar retroalimentación: «Agreguemos const para los parámetros que no se modifican — esto hará la interfaz más clara y evitará cambios accidentales».

3. Uso de STL y algoritmos

La biblioteca estándar de C++ contiene muchas soluciones listas para usar. Reinventar la rueda es un error común de los principiantes.

Qué revisar:

\n
• ¿Hay bucles manuales que se puedan reemplazar con algoritmos (std::find, std::sort, std::transform)?
\n
• ¿Se ha elegido el contenedor correcto? (std::vector para acceso aleatorio, std::list para inserciones frecuentes en el medio)
\n
• ¿Se usa std::string_view para pasar cadenas sin copiar?
\n
• ¿Se ha olvidado reserve() para std::vector cuando se conoce el tamaño?
\n

// ❌ Malo: búsqueda manual\nbool contains(const std::vector<int>& v, int val) {\n    for (size_t i = 0; i < v.size(); ++i) {\n        if (v[i] == val) return true;\n    }\n    return false;\n}\n\n// ✅ Bueno: uso de STL\nbool contains(c