Solución:
El problema con la primera versión es que si retrocede y agrega una segunda declaración a las cláusulas if o else sin recordar agregar las llaves, su código se romperá de maneras inesperadas y divertidas.
En cuanto a la mantenibilidad, es siempre más inteligente utilizar la segunda forma.
EDITAR: Ned señala esto en los comentarios, pero creo que también vale la pena vincularlo aquí. Esto no es solo una tontería hipotética de torre de marfil: https://www.imperialviolet.org/2014/02/22/applebug.html
Un problema de omitir bloques de instrucciones es la ambigüedad de lo demás. Es decir, los lenguajes inspirados en C ignoran la sangría y, por lo tanto, no tienen forma de separar esto:
if(one)
if(two)
foo();
else
bar();
De esto:
if(one)
if(two)
foo();
else
bar();
Mi patrón general es que si cabe en una línea, haré:
if(true) do_something();
Si hay una cláusula else, o si el código en el que quiero ejecutar true es de una longitud significativa, tirantes hasta el final:
if(true) {
do_something_and_pass_arguments_to_it(argument1, argument2, argument3);
}
if(false) {
do_something();
} else {
do_something_else();
}
En última instancia, todo se reduce a una cuestión subjetiva de estilo y legibilidad. El mundo de la programación general, sin embargo, se divide en dos partes (para los lenguajes que usan llaves): utilícelos todo el tiempo sin excepción, o utilícelos todo el tiempo con excepción. Soy parte del último grupo.