En su mayor parte, esta es una preferencia personal, sin embargo, hay algunas cosas a considerar.
Posibles errores
Si bien se puede argumentar que los errores causados por el olvido al complemento de los frenos son raros, por lo que he visto que ellos no ocurren de vez en cuando (no olvidar el famoso Goto IOS falla error). Así que creo que esto debería ser un factor al considerar el estilo de su código (algunas herramientas advierten sobre sangría engañosa , por lo que también depende de su cadena de herramientas) .
Válido Código (que se lee como que podría ser un error)
Incluso suponiendo que su proyecto no sufre de este tipo de errores, al leer el código es posible que vea algunos bloques de código que parecen que podrían ser errores - pero no es así, tomando algunas de sus ciclos mentales.
Comenzamos con:
if (foo)
bar();
Un desarrollador agrega un comentario útil.
if (foo)
// At this point we know foo is valid.
bar();
Más tarde, un desarrollador se expande en él.
if (foo)
// At this point we know foo is valid.
// This never fails but is too slow even for debug, so keep disabled.
// assert(is_valid(foo));
bar();
O agrega un bloque anidado:
if (foo)
while (i--) {
bar(i);
baz(i);
}
O usa una macro:
if (foo)
SOME_MACRO();
"... Dado que las macros pueden definir varias líneas de código, ¿la macro usa do {...} while (0)varias líneas? Debería porque está en nuestra guía de estilo, ¡pero es mejor que lo verifique por si acaso!"
Los ejemplos anteriores son todos códigos válidos, sin embargo, cuanto más contenido en el bloque de código, más necesita leer para asegurarse de que no haya errores.
Tal vez su estilo de código define que los bloques de varias líneas requieren una llave (no importa qué, incluso si no son código) , pero he visto este tipo de comentarios agregados en el código de producción. Cuando lo lees, hay una pequeña duda de que quien editó esas líneas por última vez se olvidó de agregar un paréntesis, a veces siento que la necesidad de verificar dos veces está funcionando según lo previsto (especialmente cuando se investiga un error en esta área del código) .
Ruido difuso
Una razón práctica para usar llaves para líneas simples es reducir el ruido diferencial .
Es decir, cambiando:
if (foo)
bar();
A:
if (foo) {
bar();
baz();
}
... hace que la línea condicional se muestre en un diff como modificada, esto agrega una sobrecarga pequeña pero innecesaria.
- las líneas se muestran como modificadas en las revisiones de código, si sus diferentes herramientas están basadas en palabras, puede ver fácilmente que solo cambió la llave, pero eso lleva más tiempo verificar si la línea no cambió en absoluto.
Dicho esto, no todas las herramientas son compatibles con la diferenciación basada en palabras, diff (svn, git, hg ... etc.) se mostrará como si toda la línea cambiara, incluso con herramientas sofisticadas, a veces es posible que necesite mirar rápidamente sobre una línea simple basado en diff para ver qué cambió.
- Las herramientas de anotación (como
git blame) mostrarán la línea como modificada, haciendo que el seguimiento del origen de una línea sea más paso para encontrar el cambio real .
Ambos son pequeños y dependen de la cantidad de tiempo que dedique a revisar o rastrear el código que confirma las líneas de código cambiadas.
Un inconveniente más tangible de tener cambios de líneas adicionales en una diferencia, su mayor probabilidad de que los cambios en el código causen conflictos que se fusionen y deben resolverse manualmente .
Hay una excepción a esto, para las bases de código que tienen {en su propia línea, no es un problema.
El argumento de ruido diferencial no se cumple si escribe en este estilo:
if (foo)
{
bar();
baz();
}
Sin embargo, esta no es una convención tan común, por lo que se agrega principalmente a la respuesta para completar (no sugerir que los proyectos deberían usar este estilo) .
