Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 525 — #563
✐
A.4. Paréntesis, llaves e indentación
La marca de fin de listado simplemente le indica a ExtractCode.cpp que ese
es el final del listado, pero la marca de comienzo incluye información sobre el subdirectorio
al que corresponde el fichero (normalmente organizado por capítulos, así
que si corresponde al Capítulo 8 debería tener una etiqueta como C08), seguido de
dos puntos y el nombre del fichero.
Como ExtractCode.cpp también crea un makefile para cada subdirectorio,
la información de cómo construir el programa y la línea de comando que se debe
usar para probarlo también se incorpora a los listados. Si un programa es autónomo
(no necesita ser enlazado con nada más) no tiene información extra. Esto también es
cierto para los ficheros de cabecera. Sin embargo, si no contiene un main() y necesita
enlazarse con algún otro, aparece un {O} después del nombre del fichero. Si ese
listado es el programa principal pero necesita ser enlazado con otros componentes,
hay una línea adicional que comienza con //{L} y continúa con el nombre de todos
los ficheros con los que debe enlazarse (sin extensiones, dado que puede variar entre
plataformas).
Puede encontrar ejemplos a lo largo de todo el libro.
Cuando un fichero debe extraerse sin que las marcas de inicio y fin deban incluirse
en el fichero extraído (por ejemplo, si es un fichero con datos para una prueba) la
marca de inicio va seguida de un ’!’.
A.4. Paréntesis, llaves e indentación
Habrá notado que el estilo de este libro es diferente a la mayoría de los estilos
C tradicionales. Por supuesto, cualquiera puede pensar que su propio estilo es más
racional. Sin embargo, el estilo que se emplea aquí tiene una lógica más simple, que
se presentará mezclada con las de otros estilos desarrollados.
El estilo está motivado por una cosa: la presentación, tanto impresa como en un
seminario. Quizá sus necesidades sean diferentes porque no realiza muchas presentaciones.
Sin embargo, el código real se lee muchas más veces de las que se escribe,
y por eso debería ser fácil de leer. Mis dos criterios más importantes son la «escaneabilidad»
(que se refiere a la facilidad con la que el lector puede comprender el
significado de una única línea) y el número de líneas que caben en una página. Lo
segundo puede sonar gracioso, pero cuando uno da una charla, distrae mucho a la
audiencia que el ponente tenga que avanzar y retroceder diapositivas, y sólo unas
pocas líneas de más puede provocar este efecto.
Todo el mundo parece estar de acuerdo en que el código que se pone dentro de
llaves debe estar indentado. En lo que la gente no está de acuerdo - y es el sitio donde
más inconsistencia tienen los estilos - es: ¿Dónde debe ir la llave de apertura Esta
única cuestión, creo yo, es la que causa la mayoría de las variaciones en los estilos
de codificación (Si quiere ver una enumeración de estilos de codificación vea C++
Programming Guidelines, de [FIXME:autores] Tom Plum y Dan Saks, Plum Hall 1991),
Intentaré convencerle de que muchos de los estilos de codificación actuales provienen
de la restricciones previas al C Estándar (antes de los prototipos de función) de
manera que no son apropiadas actualmente.
Lo primero, mi respuesta a esa pregunta clave: la llave de apertura debería ir
siempre en la misma línea que el «precursor» (es decir «cualquier cosa de la que
sea cuerpo: una clase, función, definición de objeto, sentencia if, etc». Es una regla
única y consistente que aplico a todo el código que escribo, y hace que el formateo
de código sea mucho más sencillo. Hace más sencilla la «escaneabilidad» - cuando
se lee esta línea:
525
✐
✐
✐
✐