Prefiero la versión sin llaves cuando sea posible.
La siguiente explicación es larga. Por favor, tenga paciencia conmigo. Daré una razón convincente para que prefiera este estilo. También explicaré por qué creo que el contraargumento habitual no es válido.
Las líneas (casi) vacías son un desperdicio
La razón de esto es que la llave de cierre requiere una línea adicional de código, y también la llave de apertura, según el estilo. 1
¿Es esto un gran problema? Superficialmente, no. Después de todo, la mayoría de las personas también ponen líneas vacías en su código para separar bloques lógicamente ligeramente independientes, lo que mejora enormemente la legibilidad.
Sin embargo, detesto desperdiciar el espacio vertical. Los monitores modernos en realidad tienen un amplio espacio horizontal. Pero el espacio vertical sigue siendo muy, muy limitado (a menos que use un monitor en posición vertical, lo que no es tan raro). Este espacio vertical limitado es un problema: se reconoce ampliamente que los métodos individuales deben ser lo más cortos posible y que los corchetes correspondientes (u otros delimitadores de bloque) no deben tener más de una altura de pantalla en la diferencia para que pueda ver todo el bloque sin desplazamiento
Este es un problema fundamental : una vez que ya no puede ver todo el bloque en su pantalla, se vuelve difícil de comprender.
Como consecuencia, detesto las líneas vacías redundantes. Donde las líneas vacías individuales son cruciales para delimitar bloques independientes (solo mire la apariencia visual de este texto), las líneas vacías consecutivas son un estilo muy malo en mi libro (y en mi experiencia generalmente son un signo de programadores novatos).
Del mismo modo, las líneas que simplemente sostienen una llave, y que podrían economizarse, deberían serlo. Un bloque de una sola declaración que está delimitado por llaves desperdicia una o dos líneas. Con solo 50 líneas por altura de pantalla, esto es notable.
Omitir aparatos ortopédicos tal vez no haga daño
Solo hay un argumento en contra de omitir llaves: que alguien más tarde agregará otra declaración al bloque en cuestión y olvidará agregar las llaves, cambiando así inadvertidamente la semántica del código.
De hecho, esto sería un gran problema.
Pero en mi experiencia, no lo es. Soy un programador descuidado; y, sin embargo, en mi década de experiencia en programación, honestamente puedo decir que he no una vez olvidado de añadir las llaves cuando se añade una declaración adicional a un bloque de Singleton.
Incluso me parece inverosímil que esto sea un error común: los bloques son una parte fundamental de la programación. La resolución y el alcance del nivel de bloque es un proceso mental automático e integrado para los programadores. El cerebro simplemente lo hace (de lo contrario, razonar sobre la programación sería mucho más difícil). No se requiere un esfuerzo mental adicional para recordar poner los frenos: el programador también recuerda sangrar correctamente la declaración recién agregada, después de todo; entonces el programador ya ha procesado mentalmente que hay un bloque involucrado.
Ahora, estoy no diciendo que la omisión de los apoyos no causa errores. Lo que digo es que no tenemos evidencia de una manera u otra. Simplemente no sabemos si causa daño.
Entonces, hasta que alguien pueda mostrarme datos concretos, recopilados de experimentos científicos, que demuestren que esto es realmente un problema en la práctica, esta teoría sigue siendo una " historia justa ": una hipótesis muy convincente que nunca se ha puesto a prueba, y que debe no ser utilizado como un argumento.
1 Este problema a veces se resuelve poniendo todo, incluidos los corchetes, en la misma línea:
if (condition)
{ do_something(); }
Sin embargo, creo que es seguro decir que la mayoría de las personas desprecian esto. Además, tendría los mismos problemas que la variante sin llaves, por lo que es el peor de ambos mundos.