¿Es una mala práctica usar una declaración if sin llaves? [cerrado]

He visto un código como este:

if(statement)
    do this;
else
    do this;

Sin embargo, creo que esto es más legible:

if(statement){
    do this;
}else{
    do this;
}

Dado que ambos métodos funcionan, ¿es simplemente una cuestión de preferencia cuál usar o se recomendaría de una forma sobre la otra?

El problema con la primera versión es que si regresa 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 al mantenimiento, siempre es más inteligente usar la segunda forma.

EDITAR: Ned señala esto en los comentarios, pero vale la pena vincularlo aquí, creo. Esto no es solo una mierda hipotética de la torre de marfil: https://www.imperialviolet.org/2014/02/22/applebug.html

Un problema con omitir bloques de instrucciones es la ambigüedad de lo contrario. 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 truees de longitud significativa, usa llaves todo el tiempo:

if(true) {
    do_something_and_pass_arguments_to_it(argument1, argument2, argument3);
}

if(false) {
    do_something();
} else {
    do_something_else();
}

En definitiva, se trata de una cuestión subjetiva de estilo y legibilidad. Sin embargo, el mundo de la programación general se divide en dos partes (para los idiomas que usan llaves): o úselas todo el tiempo sin excepción, o úselas todo el tiempo con excepción. Soy parte del último grupo.

Estoy usando el formateador de código del IDE que uso. Eso puede diferir, pero se puede configurar en Preferencias / Opciones.

Me gusta este:

if (statement)
{
    // comment to denote in words the case
    do this;
    // keep this block simple, if more than 10-15 lines needed, I add a function for it
}
else
{
    do this;
}

La "regla" que sigo es esta:

Si la instrucción "if" se está probando para hacer algo (funciones de llamada de IE, configurar variables, etc.), use llaves.

if($test)
{
    doSomething();
}

Esto se debe a que siento que debe dejar en claro qué funciones se están llamando y hacia dónde va el flujo del programa, en qué condiciones. Hacer que el programador entienda exactamente qué funciones se llaman y qué variables se configuran en esta condición es importante para ayudarlo a comprender exactamente lo que está haciendo su programa.

Si la instrucción "if" se está probando para dejar de hacer algo (control de flujo de IE dentro de un bucle o función), use una sola línea.

if($test) continue;
if($test) break;
if($test) return;

En este caso, lo que es importante para el programador es descubrir rápidamente cuáles son los casos excepcionales en los que no desea que se ejecute el código, y todo eso está cubierto en $ test, no en el bloque de ejecución.

Tener los aparatos correctos desde el primer momento debería ayudar a evitar que tenga que depurar esto:

if (statement)
     do this;
else
     do this;
     do that;

Use llaves para todas las declaraciones if, incluso las simples. O reescriba una declaración if simple para usar el operador ternario:

if (someFlag) {
 someVar= 'someVal1';
} else {
 someVar= 'someVal2';
}

Se ve mucho mejor así:

someVar= someFlag ? 'someVal1' : 'someVal2';

¡Pero solo use el operador ternario si está absolutamente seguro de que no hay nada más que deba ir en los bloques if / else!

Prefiero usar llaves. Agregar llaves hace que sea más fácil de leer y modificar.

Aquí hay algunos enlaces para el uso de llaves:

• Prefiero Multilínea si

• Omitir llaves: no solo es una cuestión de estilo

• Desbordamiento de pila

Desde mi experiencia, la única (muy) ligera ventaja de la primera forma es la legibilidad del código, la segunda forma agrega "ruido".

Pero con los IDE modernos y la autogeneración de código (o autocompletado), le recomiendo usar la segunda forma, no pasará más tiempo escribiendo llaves y evitará algunos de los errores más frecuentes.

Hay suficientes errores que consumen energía, la gente simplemente no debe abrir puertas por grandes pérdidas de tiempo.

Una de las reglas más importantes para recordar al escribir código es la coherencia. Cada línea de código debe escribirse de la misma manera, sin importar quién la haya escrito. Ser riguroso evita que los errores "sucedan";)

Esto es lo mismo con nombrar clara y explícitamente sus variables, métodos, archivos o con sangría correcta ...

Cuando mis alumnos aceptan este hecho, dejan de luchar contra su propio código fuente y comienzan a ver la codificación como una actividad realmente interesante, estimulante y creativa. ¡Desafían sus mentes, no sus nervios!

Es una cuestión de preferencia. Personalmente uso ambos estilos, si estoy razonablemente seguro de que no necesitaré agregar más declaraciones, utilizo el primer estilo, pero si eso es posible, utilizo el segundo. Como no puede agregar más declaraciones al primer estilo, he oído que algunas personas recomiendan no usarlo. Sin embargo, el segundo método incurre en una línea de código adicional y si usted (o su proyecto) usa este tipo de estilo de codificación, el primer método es muy preferido para declaraciones if simples:

if(statement)
{
    do this;
}
else
{
    do this;
}

Sin embargo, creo que la mejor solución a este problema está en Python. Con la estructura de bloques basada en espacios en blanco, no tiene dos métodos diferentes para crear una instrucción if: solo tiene uno:

if statement:
    do this
else:
    do this

Si bien eso tiene el "problema" de que no puedes usar los frenos en absoluto, obtienes el beneficio de que no son más líneas que el primer estilo y tienen el poder de agregar más declaraciones.

Siempre he intentado que mi código sea estándar y se vea lo más parecido posible. Esto facilita que otros lo lean cuando están a cargo de actualizarlo. Si haces tu primer ejemplo y le agregas una línea en el medio, fallará.

No funcionará

if (declaración) haz esto; y esto; si no, haz esto;

Personalmente utilizo el primer estilo solo lanzo una excepción o regreso de un método prematuramente. Como argumento Comprobación al comienzo de una función, porque en estos casos, rara vez tengo que hacer más de una cosa, y nunca hay otra.

Ejemplo:

if (argument == null)
    throw new ArgumentNullException("argument");

if (argument < 0)
    return false;

De lo contrario, uso el segundo estilo.

Mi preferencia personal es usar una mezcla de espacios en blanco y corchetes como este:

if( statement ) {

    // let's do this

} else {

    // well that sucks

}

Creo que esto se ve limpio y hace que mi código sea muy fácil de leer y, lo más importante, depurar.

Estoy de acuerdo con la mayoría de las respuestas en el hecho de que es mejor ser explícito en su código y usar llaves. Personalmente, adoptaría un conjunto de estándares de codificación y me aseguraría de que todos en el equipo los conozcan y se ajusten. Donde trabajo utilizo estándares de codificación publicados por IDesign.net para proyectos .NET.

Prefiero poner un aparato ortopédico rizado. Pero a veces, el operador ternario ayuda.

En vez de :

int x = 0;
if (condition) {
    x = 30;
} else {
    x = 10;
}

Uno simplemente debería hacer: int x = condition ? 30 : 20;

También imagine un caso:

if (condition)
    x = 30;
else if (condition1)
    x = 10;
else if (condition2)
    x = 20;

Sería mucho mejor si te pusieras la llave.