Código C++ que no da vergüenza mostrar a los colegas: estilo de código y convenciones

Cuando «funciona» no es lo principal

Imagine una situación: abre una solicitud de extracción (pull request) de otra persona en C++. El código compila, las pruebas pasan, la lógica es correcta. Pero usted pierde 40 minutos para entender lo que sucede. Las variables se llaman a, b, ptr2, las sangrías saltan de 2 a 8 espacios, y en un solo archivo se mezclan snake_case y camelCase. ¿Le suena familiar?

En el desarrollo individual, ese caos aún se puede soportar. Pero tan pronto como aparece un segundo, tercer o décimo desarrollador en el proyecto, la falta de un estilo de código C++ unificado convierte el código en un «pantano». Cada uno escribe como está acostumbrado, y el tiempo dedicado a la revisión de código crece exponencialmente.

En este artículo, analizaremos qué convenciones C++ funcionan realmente en equipo, cómo implementarlas sin dolor y por qué esto le ahorrará nervios y dinero. ¡Allá vamos!

Por qué el estilo de código no es cuestión de «verse bonito», sino de dinero

Muchos piensan que las discusiones sobre el estilo de código son una pérdida de tiempo. En la práctica, las investigaciones (por ejemplo, de Google y Microsoft) muestran que: la legibilidad del código afecta directamente la cantidad de errores. Cuando un desarrollador se esfuerza menos en descifrar lo escrito, comete menos errores al refactorizar y encuentra los problemas más rápido.

Un estándar de código C++ unificado le da al equipo tres ventajas clave:

\n
• Velocidad de incorporación. El nuevo miembro no adivina cómo se escribe aquí — simplemente mira cualquier archivo y ve el patrón.
\n
• Mínimos conflictos en la revisión de código. En lugar de «reescribe las sangrías», se discute la arquitectura y la lógica.
\n
• Automatización. Los formateadores y linters se encargan de la rutina, liberando la mente para la creatividad.
\n

La buena noticia: no necesita reinventar la rueda. Existen mejores prácticas de C++ probadas que se adaptan a cualquier proyecto.

Convenciones principales de C++: desde la nomenclatura hasta el formato

Repasemos los bloques clave que vale la pena fijar en una guía de estilo de código. Para cada punto, daré un ejemplo de «malo» y «bueno».

1. Nomenclatura: snake_case vs CamelCase vs PascalCase

En C++ históricamente se ha adoptado un enfoque híbrido. La biblioteca estándar usa snake_case, muchas empresas (Google, Microsoft) también lo prefieren para variables y funciones. Para clases y estructuras se suele usar PascalCase.

Ejemplo de mala nomenclatura:

class datamanager {\n    int numberOfElements;\n    void ProcessData(int* ptr) { ... }\n};

Problemas: clase en snake_case, método en CamelCase, sin contexto. Mejor así:

class DataManager {\n    int number_of_elements_;\n    void ProcessData(int* data_ptr) { ... }\n};

Qué se corrigió aquí:

\n
• Clase — PascalCase.
\n
• Campos — snake_case con sufijo de guion bajo para miembros privados (estilo Google).
\n
• Método — PascalCase (o snake_case, si se acordó en el equipo).
\n
• Parámetro — snake_case con sufijo _ptr, para que quede claro de inmediato que es un puntero.
\n

Consejo: elija un solo estilo para todo el proyecto. Mezclar getValue() y get_value() en un mismo archivo es el camino seguro hacia la confusión.

2. Formato: espacios, llaves y longitud de líneas

La fuente más común de disputas es dónde colocar la llave de apertura: ¿en la misma línea o en la siguiente? En C++ se acostumbra a ponerla en la misma línea (estilo K&R), pero hay variaciones.

Ejemplo de un estilo consistente:

void CalculateSum(const std::vector<int>& values) {\n    int sum = 0;\n    for (size_t i = 0; i < values.size(); ++i) {\n        sum += values[i];\n    }\n    return sum;\n}

Aquí todo es uniforme: llave después de if, fo