Apéndice A. Estilo de codificación

Tabla de contenidos

A.1. General
A.2. Nombres de fichero
A.3. Marcas comentadas de inicio y fin
A.4. Paréntesis, llaves e indentación
A.5. Nombres para identificadores
A.6. Orden de los #includes
A.7. Guardas de inclusión en ficheros de cabecera
A.8. Uso de los espacios de nombres
A.9. Utilización de require() y assure()

Este apéndice no trata sobre indentación o colocación de paréntesis y llaves, aunque sí que se menciona. Trata sobre las directrices generales que se usan en este libro para la organización de los listados de código.

Aunque muchas de estas cuestiones se han tratado a lo largo del libro, este apéndice aparece al final de manera que se puede asumir que cada tema es FIXME:juego limpio, y si no entiende algo puede buscar en la sección correspondiente.

Todas las decisiones sobre estilo de codificación en este libro han sido consideradas y ejectuadas deliberadamente, a veces a lo largo de períodos de años. Por supuesto, cada uno tiene sus razones para organizar el código en el modo en que lo hace, y yo simplemente intento explicarle cómo llegué a tomar mi postura y las restricciones y factores del entorno que me llevaron a tomar esas decisiones.

A.1. General

En el texto de este libro, los identificadores (funciones, variables, y nombres de clases) aparecen en negrita. Muchas palabras reservadas también son negritas, exceptuando aquellas que se usan tan a menudo que escribirlas en negrita puede resultar tedioso, como «class» o «virtual».

Utilizo un estilo de codificación particular para los ejemplos de este libro. Se desarrolló a lo largo de varios años, y se inspiró parcialmente en el estilo de Bjarne Stroustrup en el The C++ Programming Language [85] original. El asunto del estilo de codificación es ideal para horas de acalorado debate, así que sólo diré que no trato de dictar el estilo correcto a través de mis ejemplos; tengo mis propios motivos para usar el estilo que uso. Como C++ es un lenguaje de formato libre, cada uno puede continuar usando el estilo que le resulte más cómodo.

Dicho esto, sí haré hincapié en que es importante tener un estilo consistente dentro de un proyecto. Si busca en Internet, encontrará un buen número de herramientas que se pueden utilizar para reformatear todo el código de un proyecto para conseguir esa valiosa consistencia.

Los programas de este libro son ficheros extraídos automáticamentente del texto del libro, lo que permite que se puedan probar para asegurar que funcionan correctamente [86]. De ese modo, el código mostrado en el libro debería funcionar sin errores cuando se compile con una implementación conforme al Estándar C++ (no todos los compiladores soportan todas las características del lenguaje). Las sentencias que deberían causar errores de compilación están comentadas con //! de modo que se pueden descubrir y probar fácilmente de modo automático. Los errores descubiertos por el autor aparecerán primero en la versión electrónica del libro (www.BruceEckel.com) y después en las actualizaciones del libro.

Uno de los estándares de este libro es que todos los programas compilarán y enlazarán sin errores (aunque a veces causarán advertencias). Algunos de los programas, que demuestran sólo un ejemplo de codificación y no representan programas completos, tendrán funciones main() vacías, como ésta:

int main() {}

Esto permite que se pueda enlazar el programa sin errores.

El estándar para main() es retornar un int, pero C++ Estándar estipula que si no hay una sentencia return en main(), el compilador generará automáticamente código para return 0. Esta opción (no poner un return en main()) se usa en el libro (algunos compiladores producen advertencias sobre ello, pero es porque no son conformes con C++ Estándar).



[85] FIXME:Ibid.

[86] (N. de T.) Se refiere al libro original. En esta traducción, los programas son ficheros externos incluidos en el texto.