Tabla de contenidos
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.
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 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.
en el The C++ Programming Language [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).