if-statement - utilizar - que son las llaves en programacion

¿Es una mala práctica usar un enunciado if sin corchetes?

Question

He visto un código como este:

if(statement)
    do this;
else
    do this;

No me gusta eso, creo que esto es más limpio y más legible

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

¿Es esto simplemente una cuestión de preferencia o se recomendaría una manera sobre la otra?

Answer 1

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), recomiendo encarecidamente utilizar el segundo formulario, no perderás tiempo extra escribiendo llaves y evitarás algunos de los errores más frecuentes.

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

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

Esto es lo mismo con nombrar de manera clara y explícita sus variables, métodos, archivos o con sangrarlos correctamente ...

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!

Answer 2

El problema con la primera versión es que si regresas y añades una segunda declaración a las cláusulas if o else sin recordar agregar las llaves, tu código se dividirá en formas inesperadas y divertidas.

En términos de mantenimiento, siempre es más inteligente usar la segunda forma.

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

Answer 3

Es una cuestión de preferencia. Yo 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 escuchado 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 las declaraciones simples de if:

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

Sin embargo, creo que la mejor solución para 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 una:

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 hay más líneas que el primer estilo y tiene el poder de agregar más declaraciones.

Answer 4

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é de que todos en el equipo los conozcan y cumplan. Donde trabajo, utilizamos estándares de codificación publicados por IDesign.net para proyectos .NET.

Answer 5

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;
}

Answer 6

La "regla" que sigo es esta:

Si la instrucción "if" está probando para hacer algo (IE llama a funciones, configura variables, etc.), use llaves.

if($test)
{
    doSomething();
}

Esto se debe a que creo que necesita dejar en claro qué funciones se están llamando y hacia dónde se dirige el flujo del programa, bajo qué condiciones. Es importante que el programador comprenda exactamente qué funciones se llaman y qué variables se establecen en esta condición para ayudarlo a comprender exactamente qué está haciendo su programa.

Si la instrucción "if" está probando para dejar de hacer algo (control de flujo 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 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 eso está todo cubierto en $ test, no en el bloque de ejecución.

Answer 7

Mi patrón general es que si encaja en una línea, lo haré:

if(true) do_something();

Si hay una cláusula else, o si el código que quiero ejecutar en true es de una longitud significativa, corrige todo el camino:

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

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

En definitiva, 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 idiomas que usan llaves): o las usa todo el tiempo sin excepción, o las usa todo el tiempo con excepción. Soy parte del último grupo.

Answer 8

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.

Answer 9

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

Ejemplo:

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

if (argument < 0)
    return false;

De lo contrario, uso el segundo estilo.

Answer 10

Prefiero poner un corsé. Pero a veces, el operador ternario ayuda.

En lugar de :

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

Uno debería simplemente hacer: int x = condition ? 30 : 20; 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 pones la llave.

Answer 11

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:

• Prefiere Multiline si

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

• Desbordamiento de pila

Answer 12

Siempre he intentado hacer que mi código sea estándar y me parezca 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) hacer esto; y esto; otra cosa haz esto;

Answer 13

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

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

Answer 14

Un problema con la omisión de bloques de instrucciones es la ambigüedad de los demás. Es decir, los lenguajes inspirados en C ignoran la indentación y, por lo tanto, no hay manera de separar esto:

if(one)
    if(two)
        foo();
    else
        bar();

De esto:

if(one)
    if(two)
        foo();
else
    bar();

Answer 15

Use llaves para todos los enunciados if incluso los simples. O bien, vuelva a escribir una instrucció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!