Formato de Instrucciones if

Question

Esto no es una guerra santa, esta no es una pregunta de "cual es mejor".

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

if (x) print "x is true";

if(x) 
    print "x is true";

Como contraposición a

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

Si el formato de su sola declaración de ifs sin soportes o conocer un programador que hace, lo que le llevó a usted/a adoptar este estilo en el primer lugar?Estoy especialmente interesado en lo que los beneficios que esto le ha traído.

Actualización:Como la respuesta más popular ignora la pregunta (incluso si se presenta la mayoría de cuerda asesoramiento), he aquí un resumen de los soportes profesionales.

1. Compacidad
2. Más legible para algunos
3. Soportes de invocar alcance, el cual tiene un ancho de sobrecarga en algunos casos

Answer 1

Me encuentro esto:

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

mejor que esto:

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

De esta manera, si yo (o alguien más) regresa a este código para agregar más código a una de las ramas, yo no tendría que preocuparse de olvidarse de rodear el código entre llaves.Nuestros ojos van a ver visualmente la sangría como pistas de lo que estamos tratando de hacer, pero la mayoría de los idiomas no.

Answer 2

Me desagrada cualquier estilo que pone el caso de la prueba y el cuerpo en la misma línea.

Esto es debido a que comparten la línea hace que sea imposible establecer un punto de interrupción en el caso del cuerpo en muchos depuradores porque los puntos de interrupción son típicamente número de línea de base.

Answer 3

Siempre el uso de llaves es una buena idea, pero la respuesta estándar que siempre da "lo que si alguien añade una línea de código y se olvida de agregar las llaves?" es bastante débil razón.

Hay un error sutil que puede ser introducido por no tener las llaves desde el principio.Me ha sucedido un par de veces y he visto pasar a otros programadores.

Comienza inocentemente, con una simple instrucción if.

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

Que es todo bien y bueno.

Entonces llega alguien y añade otra condición a la si.No pueden añadir usando && a la declaración de si misma, porque la lógica sería incorrecto, por lo que añade otro si.Ahora tenemos:

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

¿Ve usted el problema?Se puede ver a la derecha, pero el compilador ve de otra manera.Se ve como esto:

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

Lo que significa algo completamente diferente.El compilador no le importa el formato.La cosa va con el más cercano si.Los humanos, por otro lado, se basan en el formato y fácilmente se puede perder el problema.

Answer 4

Yo siempre uso

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

dejando fuera de las llaves puede resultar en alguien el mantenimiento del código pensando equivocadamente que están añadiendo a la cláusula if si se agrega una línea después de la línea actual.

Answer 5

Yo uso

if (x)
{
    DoSomething();
}

para varias líneas, pero yo prefiero sin soporte de los trazadores de líneas uno:

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

Me parece extrañas soportes visuales ofensivo, y nunca he hecho uno de los mencionados errores para no añadir corchetes cuando la adición de otra declaración.

Answer 6

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

porque me gusta cuando los bloques de código de línea (incluyendo sus llaves).

Answer 7

Si I código:

if(x) 
    print "x is true";

y 6 meses después de añadir una nueva línea, la presencia de llaves hace que sea mucho menos probable que voy a tipo de

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

Así llaves hacer tales errores lógicos más fácil de leer y evitar, me parece.

Answer 8

Como Matt (3 arriba), yo prefiero:

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

y

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

Creo que es bastante extraño pensar que alguien puede venir a lo largo de más tarde y NO se dan cuenta de que tienen que agregar las llaves para formar un multi-línea si el bloque.Si que está más allá de sus capacidades, me pregunto qué otras cosas son!

Answer 9

Sola instrucción si los bloques que carecen de los apoyos:

Pros:

• menos caracteres
• aspecto más limpio

Contras:

• uniformidad:no se si todos los bloques tienen el mismo aspecto
• potencial de errores al agregar instrucciones para el bloque:un usuario puede olvidarse de agregar las llaves y la nueva declaración de no estar cubierto por el si.

Como en:

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

Answer 10

Tiendo a una sola línea cuando estoy probando para condiciones de interrupción en el principio de una función, porque me gusta mantener este código tan simple y ordenada como sea posible

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

     ...
}

También, si me quieren evitar los apoyos y en línea si una cláusula de código, puedo sola línea, por lo que es obvio para cualquiera agregar nuevas líneas para el caso de que los soportes no necesita ser añadido

Answer 11

Yo uso

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

• Todo lo que siempre debe tener refuerzos.Aunque ahora sólo tengo una línea en el bloque if, me hizo añadir más tarde.
• No pongo las llaves en sus propias líneas, porque es inútil desperdicio de espacio.
• Rara vez me ponga el bloque en la misma línea que el condicional para mejorar la legibilidad.

Answer 12

Joel Spolsky escribió un buen artículo: Hacer Mal De Código Incorrecto

Se trata específicamente de este tema...

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 malo con ella, pero el hecho de que la sola declaración de el cuerpo de la ifstatement no es encerrada entre llaves pueden estar molestando, porque usted podría estar pensando en la parte de atrás de su cabeza, dios mío, que alguien puede insertar otra línea de código allí

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

... y te olvides de añadir las llaves, y por lo tanto accidentalmente hacer foo(i)incondicional!Así que cuando usted ve los bloques de código que no están en los apoyos, usted podría sentido de que sólo un pequeño, pequeñito, soupçon de la impureza que hace inquieto.

Él sugiere que...

... deliberadamente arquitecto de su código de tal manera que su nariz para la impureza hace el código más probabilidad de ser correcta.

Answer 13

No me gusta el uso de llaves cuando no son necesarios.Me siento como aumenta el número de líneas en un método y la hace ilegible.Así que casi siempre van de los siguientes:

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

Y así sucesivamente.Si alguien necesita agregar otra declaración, a continuación, sólo tiene que añadir las llaves.Incluso si usted no tiene un R# o algo similar es un pequeño negocio.

Aún así, hay algunos casos que yo uso brackets incluso si sólo hay una línea en la declaración, y es que si la línea es especialmente largo, o si necesito comentarios dentro de la que 'si'.Básicamente, sólo tiene que utilizar lo que parece más agradable a mis ojos para mirar.

Answer 14

El espacio en blanco es tu amigo ....

pero, de nuevo, que me gusta:

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

Answer 15

En serio, ¿cuándo fue la última vez que había un error en cualquiera de código en cualquier lugar que fue la causa de que alguien lo hiciera:

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

Sí, nunca...* La única verdadera 'pro' es que coincida con el estilo de los alrededores de código y salir de la estética batallas a los niños que acaba de salir de la universidad.

*(con la salvedad de ser cuando foo();bar();fue una expansión de macro, pero eso es un problema w/ macros, no se llaves w/ ifs.)

Answer 16

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

Siempre tipo de apoyos.Es sólo un buen hábito.En comparación a pensar, escribir no es "trabajo".

Nota el espacio antes de la condicional.Que le ayuda a verse no como una llamada de método.

Answer 17

Otra forma sería escribir:

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

Este será práctico si desea almacenar un valor de comparación de una condición simple, así:

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

Answer 18

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

La apertura y el cierre de corsé en la misma columna facilita la búsqueda de no coincidentes de los apoyos, y visualmente aísla el bloque.Llave de apertura en la misma columna como "si" hace que sea fácil ver que el bloque es parte de un condicional.El extra de espacio en blanco alrededor de la cuadra creado por las filas que contienen sólo los apoyos hace que sea fácil para que lo saquen de la estructura lógica cuando skimreading código.Siempre de forma explícita el uso de llaves ayuda a evitar problemas a la hora de editar el código más adelante y confundida que las declaraciones son parte de la condicional y que no son - sangría puede no coincidir con la realidad, pero estar encerrada entre llaves siempre.

Answer 19

Acerca de la única vez que no hay refuerzo parece ser aceptado es cuando comprobación de parámetros variables en el 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 compacto.El programador no tiene que vadear a través de la onu-es necesario {}'s cuando es bastante obvio que:

• el método que sale en cualquier rama verdadera
• es bastante obvio que estas son todas 1-revestimientos

Dicho esto, yo siempre iba a {} para la lógica del programa por las razones expresadas por los demás.Al colocar los brackets, es demasiado fácil mentalmente llave cuando no hay e introducir sutiles defectos de código.

Answer 20

H8ers maldita sea realmente yo no soy uno de reglas dogmáticas.En ciertas situaciones, yo en realidad va a favorecer la compacidad si no se ejecuta a través de una cierta anchura, 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 añadido de animar a la gente a la lógica abstracta de métodos (como yo he hecho) en lugar de mantener la formación de grumos más lógica en si anidadas-los demás bloques.También se ocupa tres líneas en lugar de siete, lo que podría hacer que sea posible para no tener que hacer scroll para ver varios métodos, o cualquier otro código.

Answer 21

Yo prefiero los corchetes estilo, principalmente porque da a los ojos un claro inicio y punto de parada.Esto hace que sea más fácil ver lo que realmente está contenida en la declaración, y que en realidad es una declaración de si.Una cosa pequeña, tal vez, pero por eso lo uso.

Answer 22

en la medida que es consistente entre el equipo de trabajo en el que no importa demasiado

que todo el mundo hace lo mismo es lo principal

Answer 23

Horquillado de su one-liner declaraciones y si tiene la considerable sane-haciendo ventaja de proteger a usted de dolores de cabeza si, en algún momento posterior, usted (u otros codificadores de mantener o alterar su código) necesita añadir declaraciones a alguna parte de ese bloque condicional.

Answer 24

Si haces algo como esto:

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

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

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

Answer 25

Si es una línea de si (y, opcionalmente, una línea de otra persona) yo prefiero no utilizar los corchetes.Es más legible y concisa.Yo digo que lo prefiero porque es puramente una cuestión de preferencia.Aunque creo que tratar de imponer una norma que se debe utilizar siempre las llaves es un poco tonto.

Si usted tiene que preocuparse de que alguien la adición de otra línea para el cuerpo de la instrucción if y no añadir el (y solo requiere) frenos, creo que tienen problemas más grandes que sub-bizantino estándares de codificación.

Answer 26

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

Yo nunca uso superfluo espacios más allá de las pestañas, pero siempre incluyendo los soportes ahorra un montón de tiempo.

Answer 27

No me gusta llaves de cierre en la misma línea con el seguimiento de palabras clave:

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

Esto hace que sea más difícil de quitar/comentario-sólo la cláusula else.Poniendo el seguimiento de palabras clave en la línea siguiente, puedo aprovechar, por ejemplo, los editores que me deja seleccionar un rango de líneas, y comentar/descomentar todos a la vez.

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

Answer 28

Yo siempre prefiero este:

if (x) doSomething();

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

Pero siempre dependerá de la lengua y de las acciones que estamos haciendo.A veces me gusta poner a los apoyos y a veces no.Depende del código, pero me codificación como tiene que escribir una vez, volver a escribir diez veces, y leído cientos de veces;así que, hagamos lo que quieres y como quieres leer y entender más rápidamente

Answer 29

No importa qué, esta es la forma en que me vaya!Parece la mejor.

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

Answer 30

Si eres curioso lo de los nombres para los distintos códigos de estilos de formato son, Wikipedia tiene un artículo sobre Guión Estilos.