c - statement - if else if

Formateo de if Declaraciones

Question

Esta no es una guerra santa, no se trata de "lo que es mejor".

¿Cuáles son las ventajas de utilizar el siguiente formato para declaración única si bloques.

if (x) print "x is true";

if(x) 
    print "x is true";

Opuesto a

if (x) { print "x is true"; }
if(x) {
    print "x is true";    
}

Si formatea su declaración individual si no tiene corchetes o si conoce a un programador que sí lo hace, ¿qué los llevó a adoptar este estilo en primer lugar? Estoy específicamente interesado en los beneficios que esto te ha traído.

Actualización : como la respuesta más popular ignora la pregunta real (incluso si presenta el consejo más sensato), aquí hay un resumen de los profesionales sin soporte.

1. Compacidad
2. Más legible para algunos
3. Los corchetes invocan el alcance, que tiene una carga teórica en algunos casos

Answer 1

Alterar su línea única si las declaraciones tienen la considerable ventaja de sanación que lo protege de dolores de cabeza si, en algún momento posterior, usted (u otros programadores que mantienen o alteran su código) necesitan agregar declaraciones a alguna parte de ese bloque condicional.

Answer 2

Como Matt (3 arriba), prefiero:

if (x)
{
    ...statement1
    ...statement2
}

y

if (x)
    ...statement
else
    ...statement

Creo que es bastante extraño pensar que alguien puede venir más tarde y NO darse cuenta de que tienen que agregar llaves para formar un bloque multilínea. Si eso está más allá de sus capacidades, me pregunto qué otras cosas son.

Answer 3

Declaración única si los bloques carecen de llaves:

Pros:

• menos caracteres
• mirada más limpia

Contras:

• uniformidad: no todos los bloques tienen el mismo aspecto
• potencial de errores cuando se agregan declaraciones al bloque: un usuario puede olvidarse de agregar las llaves y la nueva declaración no estaría cubierta por el if.

Como en:

if(x) 
    print "x is true";
    print "something else";

Answer 4

El espacio en blanco es tu amigo ...

pero, nuevamente, me gusta:

if (foo)
{
    Console.WriteLine("Foobar");
}

Answer 5

En serio, ¿cuándo fue la última vez que tuvo un error en un código en cualquier lugar que fue causa de que alguien lo haya hecho?

if (a)
  foo();
  bar();

Sí, nunca ... * El único "profesional" real aquí es simplemente hacer coincidir el estilo del código circundante y dejar las batallas estéticas a los niños que acaban de salir de la universidad.

* (es una advertencia cuando foo (); bar (); era una macro expansión, pero eso es un problema con macros, no con llaves c / ifs).

Answer 6

Encuentro esto

if( true ) {
    DoSomething();
} else {
    DoSomethingElse();
}

mejor que esto:

if( true )
    DoSomething();
else
    DoSomethingElse();

De esta forma, si yo (u otra persona) vuelvo a este código más tarde para agregar más código a una de las ramas, no tendré que preocuparme de olvidar rodear el código entre llaves. Nuestros ojos verán visualmente la sangría como pistas de lo que estamos tratando de hacer, pero la mayoría de los idiomas no lo harán.

Answer 7

No me gusta usar aparatos ortopédicos cuando no son necesarios. Siento que aumenta la cantidad de líneas en un método y lo hace ilegible. Así que casi siempre intento lo siguiente:

if (x)
   print "x is true"
for (int i=0; i<10; i++)
   print "y is true"

Etcétera. Si alguien necesita agregar otra declaración, entonces puede simplemente agregar las llaves. Incluso si no tiene R # o algo similar, es un negocio muy pequeño.

Aún así, hay casos en los que usaré frenos incluso si solo hay una línea en el enunciado, y eso es si la línea es especialmente larga, o si necesito comentarios dentro de ese ''si''. Básicamente, uso lo que sea más agradable para mis ojos.

Answer 8

Prefiero el estilo entre corchetes, principalmente porque le da a los ojos un claro punto de inicio y parada. Hace que sea más fácil ver lo que realmente está contenido en la declaración, y que en realidad es una declaración if. Algo pequeño, tal vez, pero es por eso que lo uso.

Answer 9

Si codigo:

if(x) 
    print "x is true";

y 6 meses después necesitan agregar una nueva línea, la presencia de llaves hace que sea mucho menos probable que escriba

if(x) 
    print "x is true";
    print "x is still true";

lo que resultaría en un error lógico, en comparación con:

if(x) { 
    print "x is true";
    print "x is still true";
}

De modo que las llaves me ayudan a leer y evitar esos errores lógicos.

Answer 10

Si es una línea de if (y opcionalmente una línea de else) prefiero no usar los corchetes. Es más legible y conciso. Yo digo que lo prefiero porque es puramente una cuestión de preferencia. Aunque creo que intentar imponer un estándar que siempre debes usar los frenos es una tontería.

Si tiene que preocuparse de que alguien agregue otra línea al cuerpo de la declaración if y no agregue los refuerzos (solo necesarios), creo que tiene problemas mayores que los estándares de codificación sub-byzantine.

Answer 11

Si haces algo como esto:

if(x)
{
    somecode;
}
else
{
    morecode;
}

Esto funciona mejor para el control de fuente y las directivas de preprocesador en el código que vive mucho tiempo. Es más fácil agregar un # si más o menos sin romper inadvertidamente la declaración o tener que agregar líneas adicionales.

es un poco extraño acostumbrarse, pero funciona bastante bien después de un tiempo.

Answer 12

Tiendo solo una línea cuando estoy probando las condiciones de descanso al comienzo de una función, porque me gusta mantener este código lo más simple y ordenado posible.

public void MyFunction(object param)
{
     if (param == null) return;

     ...
}

Además, si encuentro que quiero evitar las llaves y el código de la cláusula if en línea, puedo alinearlas solo, así que es obvio para cualquiera que agregue líneas nuevas si se deben agregar corchetes.

Answer 13

Yo siempre uso

if(x) 
{
    print "x is true";    
}

omitir las llaves puede hacer que alguien mantenga el código pensando erróneamente que están agregando a la cláusula if si agregan una línea después de la línea actual.

Answer 14

siempre y cuando sea consistente entre el equipo en el que trabajas, entonces no importa demasiado

que todos hacen lo mismo es lo principal

Answer 15

yo suelo

if (cond) {
  ...
} else {
  ...
}

• Todo debería tener siempre llaves. Incluso si ahora solo tengo una línea en el bloque if, hice agregar más más tarde.
• No pongo los frenos en sus propias líneas porque es inútil perder espacio.
• Raramente pongo el bloque en la misma línea que el condicional para la legibilidad.

Answer 16

yo suelo

if (x) { DoSomething(); }

para líneas múltiples, pero prefiero una línea sin soporte:

if (x) DoSomething(); else DoSomethingElse();

Considero que los paréntesis externos son visualmente ofensivos, y nunca he cometido uno de los errores antes mencionados al no agregar corchetes al agregar otra afirmación.

Answer 17

No me gusta mucho ningún estilo que coloque la prueba y el cuerpo del if en la misma línea.

Esto se debe a que compartir la línea hace que sea imposible establecer un punto de interrupción en el cuerpo de if en muchos depuradores, ya que los puntos de interrupción generalmente se basan en números de línea.

Answer 18

if
{
// code
}
else 
{
// else code
}

porque me gusta cuando los bloques de código se alinean (incluyendo sus llaves).

Answer 19

if (x)
{
    print "x is true";
}

Al abrir y cerrar la abrazadera en la misma columna, es más fácil encontrar tirantes desiguales y aísla visualmente el bloque. Abrir la llave en la misma columna como "si" hace que sea fácil ver que el bloque es parte de un condicional. El espacio en blanco adicional alrededor del bloque creado por las filas que contienen solo llaves hace que sea fácil elegir la estructura lógica cuando se escanea el código. Usar llaves de forma explícita siempre ayuda a evitar problemas cuando las personas editan el código más tarde y malinterpretan qué afirmaciones son parte del condicional y cuáles no: la sangría puede no coincidir con la realidad, pero estar entre llaves siempre lo será.

Answer 20

if (x) {
    print "x is true";    
}
else {
    do something else;
}

Siempre escribo llaves. Es solo un buen hábito. En comparación con pensar, escribir no es "trabajo".

Tenga en cuenta el espacio antes del condicional. Eso ayuda a que no se vea como una llamada a un método.

Answer 21

Aproximadamente, el único momento en el que parece que no se acepta el uso de abrazaderas es cuando las variables de control de parámetros se muestran al inicio de un método:

public int IndexOf(string haystack, string needle)
{
    // check parameters.
    if (haystack == null)
        throw new ArgumentNullException("haystack");
    if (string.IsNullOrEmpty(needle))
        return -1;

    // rest of method here ...

El único beneficio es la compacidad. El programador no tiene que pasar a través de {} s innecesarios cuando es bastante obvio que:

• el método sale en cualquier rama verdadera
• es bastante obvio que estos son todos 1-liners

Dicho esto, siempre {} para la lógica del programa por las razones expresadas por otros. Cuando sueltas los frenos, es muy fácil pararte mentalmente cuando no está allí e introducir defectos sutiles en el código.

Answer 22

Usar siempre llaves es una buena idea, pero la respuesta estándar siempre es "¿y si alguien agrega una línea de código y olvida agregar llaves?" es una razón bastante débil.

Hay un error sutil que se puede introducir al no tener los frenos desde el principio. Me ha sucedido un par de veces y lo he visto suceder a otros programadores.

Empieza, inocentemente, con una simple declaración if.

if (condition)
    do_something();
else
    do_something_else();

Esto es bueno y fabuloso.

Entonces alguien viene y agrega otra condición al if. No pueden agregarlo usando && a la instrucción if en sí porque la lógica sería incorrecta, por lo que agregan otra si. Ahora tenemos:

if (condition)
    if (condition2)
        do_something();
else
    do_something_else();

¿Ves el problema? Puede parecer correcto, pero el compilador lo ve de manera diferente. Lo ve así:

if (condition)
    if (condition2)
        do_something();
    else
        do_something_else();

Lo que significa algo completamente diferente. El compilador no se preocupa por formatear. El resto va con el más cercano si. Los humanos, por otro lado, confían en el formateo y pueden fácilmente perder el problema.

Answer 23

/* I type one liners with brackets like this */
if(0){return(0);}
/* If else blocks like this */
if(0){
    return(0);
}else{
    return(-1);
}

Nunca utilizo espacios en blanco superfluos más allá de las pestañas, pero siempre incluir los corchetes ahorra un montón de tiempo.

Answer 24

No me gusta cerrar llaves en la misma línea con la siguiente palabra clave:

if (x) { print "x is true"; } else { do something else; }

Esto hace que sea más difícil eliminar / comentar solo la cláusula else. Al poner la palabra clave follow en la línea siguiente, puedo aprovechar, por ejemplo, los editores que me permiten seleccionar un rango de líneas y comentar / descomentar todas a la vez.

if (x) { print "x is true"; } //else { // do something else; //}

Answer 25

Yo siempre prefiero esto:

if (x) doSomething();

if (x) {
    doSomthing();
    doOtherthing();
}

Pero siempre depende del lenguaje y las acciones que estás haciendo. A veces me gusta poner llaves y otras veces no. Depende del código, pero estoy codificando como tengo que escribir una vez, volver a escribir diez veces y leer cien veces; entonces, hazlo como quieras y desees leer y entender más rápido

Answer 26

¡No importa qué, esta es la forma en que voy! Se ve mejor

If(x)
{
    print "Hello World !!"
}
Else
{
    print "Good bye!!"
}

Answer 27

Otra forma sería escribir:

(a==b) ? printf("yup true") : printf("nop false");

Esto será práctico si desea almacenar un valor que compare una condición simple, así:

int x = (a==b) ? printf("yup true") : printf("nop false");

Answer 28

Los malditos sean. No soy realmente una persona para las reglas dogmáticas. En determinadas situaciones, en realidad voy a favorecer la compacidad si no se ejecuta en un ancho determinado, por ejemplo:

if(x > y)      { xIsGreaterThanY(); }
else if(y > x) { yIsGreaterThanX; }
else           { xEqualsY(); }

Esto es mucho más legible para mí que:

if( x > y ){
    xIsGreaterThanY(); 
}else if( x < y){
    yIsGreaterThanX();
}else{
    xEqualsY();
}

Esto tiene el beneficio adicional de alentar a las personas a que abstraigan la lógica en métodos (como lo he hecho) en lugar de seguir agrupando más lógica en bloques anidados if-else. También ocupa tres líneas en lugar de siete, lo que podría permitir no tener que desplazarse para ver varios métodos u otro código.

Answer 29

Joel Spolsky escribió un buen artículo: Hacer que el código incorrecto se vea mal

Él aborda específicamente este problema ...

if (i != 0)  
    foo(i);

En este caso, el código es 100% correcto; se ajusta a la mayoría de las convenciones de codificación y no hay nada de malo en ello, pero el hecho de que el cuerpo de declaración única de ifstatement no esté entre llaves puede molestarlo, porque podría estar pensando en la parte posterior de su cabeza, caramba, alguien podría insertar otra línea de código allí

if (i != 0)
    bar(i);
    foo(i);

... y olvida agregar los frenos, y así accidentalmente hacer foo (i) incondicional! Entonces, cuando ve bloques de código que no están entre llaves, puede sentir solo una pequeña, pequeñita, falta de limpieza que lo hace sentir incómodo.

Él sugiere que tú ...

... diseñe deliberadamente su código de tal manera que su nariz por suciedad haga que su código sea más correcto.

Answer 30

Si tiene curiosidad sobre cuáles son los nombres de los diversos estilos de formato de código, Wikipedia tiene un artículo sobre estilos de sangrado .