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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 527 — #565
✐
A.4. Paréntesis, llaves e indentación
float y;
{
/* body here */
}
Aquí, quedaría bastante mal poner la llave de apertura en la misma línea, así
que nadie lo hacía. Sin embargo, había distintas opiniones sobre si las llaves debían
indentarse con el cuerpo del código o debían dejarse a nivel con el «precursor». De
modo que tenemos muchos estilos diferentes.
Hay otros argumentos para poner la llave en la línea siguiente a la declaración
(de una clase, struct, función, etc). Lo siguiente proviene de un lector, y lo presento
aquí para que sepa a qué se refiere.
Los usuarios experimentado de vi (vim) saben que pulsar la tecla «]» dos veces
lleva el cursor a la siguiente ocurrencia de «{» (o ˆL) en la columna 0. Esta característica
es extremadamente útil para moverse por el código (saltando a la siguiente
defición de función o clase). [Mi comentario: cuando yo trabajaba en Unix, GNU
Emacs acababa de aparecer y yo me convertí en un fan suyo. Como resultado, vi
nunca ha tenido sentido para mí, y por eso yo no pienso en términos de «situación
de columna 0». Sin embargo, hay una buena cantidad de usuarios de vi ahí fuera, a
los que les afecta esta característica.]
Poniendo la «{» en la siguiente línea se eliminan algunas confusiones en sentencias
condicionales complejas, ayudando a la escaneabilidad.
if (cond1
&& cond2
&& cond3) {
statement;
}
Lo anterior [dice el lector] tiene una escaneabilidad pobre. Sin embargo,
if (cond1
&& cond2
&& cond3)
{
statement;
}
separa el if del cuerpo, mejorando la legibilidad. [Sus opiniones sobre si eso es
cierto variarán dependiendo para qué lo haya usado.]
Finalmente, es mucho más fácil visualizar llaves emparejadas si están alineadas
en la misma columna. Visualmente destacan mucho más. [Fin del comentario del
lector]
El tema de dónde poner la llave de apertura es probablemente el asunto en el que
hay menos acuerdo. He aprendido a leer ambas formas, y al final cada uno utiliza
la que le resulta más cómoda. Sin embargo, he visto que el estándar oficial de codificación
de Java (que se puede encontar en la página de Java de Sun) efectivamente
es el mismo que yo he presentado aquí - dado que más personas están empezando a
programar en ambos lenguajes, la consistencia entre estilos puede ser útil.
Mi enfoque elimina todas las excepciones y casos especiales, y lógicamente produce
un único estilo de indentación, Incluso con un cuerpo de función, la consisten-
527
✐
✐
✐
✐