language agnostic - test - ¿Cuál es el estilo preferido para los enunciados de decisión única y de acción?

readability test

Question

En el caso de los idiomas que admiten decisión única y acción sin corchetes, como el siguiente ejemplo:

if (var == true)
    doSomething();

¿Cuál es la forma preferida de escribir esto? ¿Deberían usarse siempre corchetes, o debería dejarse su uso como preferencia del desarrollador individual? Además, esta práctica depende del tamaño del bloque de código, como en el siguiente ejemplo:

if (var == 1)
    doSomething(1);
else if (var > 1 && var < 10)
    doSomething(2);
else
{
    validate(var);
    doSomething(var);
}

Answer 1

Nuestro jefe nos hace poner {} después de una declaración de decisión sin importar qué, incluso si se trata de una declaración única. Es realmente molesto agregar dos líneas adicionales. La única excepción son los operadores ternarios.

Supongo que es bueno que tenga mi monitor de código en orientación vertical a 1200x1600.

Answer 2

Realmente no hay una respuesta correcta. Para esto están los estándares de codificación dentro de la compañía. Si puede mantenerlo constante en toda la empresa, será fácil de leer. Personalmente me gusta

if ( a == b)    {
    doSomething();
}
else {
    doSomething();
}

pero esta es una guerra santa.

Answer 3

Ruby obvia bien un problema en la discusión. El estándar para un trazador de líneas es:

do_something if (a == b)

y para una línea múltiple:

if (a == b)
  do_something
  do_something_else
end

Esto permite declaraciones concisas de una línea, pero te obliga a reorganizar la declaración si pasas de una a varias líneas.

Esto no está (todavía) disponible en Java, ni en muchos otros idiomas, AFAIK.

Answer 4

Siempre he usado corchetes en todo momento, excepto en el caso en que estoy verificando una variable para NULL antes de liberarla, como es necesario en C

En ese caso, me aseguro de que quede claro que se trata de una declaración única al mantener todo en una línea, así:

if (aString) free(aString);

Answer 5

Chalk este por falta de experiencia, pero durante mi período de siete años como mono de código, nunca he visto a nadie cometer el error de no agregar llaves cuando se agrega código a un bloque que no tiene llaves. Eso es precisamente cero veces.

Y antes de que los wisecrackers lleguen a eso, no, la razón no fue que "todos usen llaves".

Entonces, una pregunta sincera: realmente me gustaría obtener respuestas reales en lugar de solo votos a la baja: ¿eso realmente sucede?

(Editar: He escuchado suficientes historias de terror sobre outsourcing para aclarar un poco: ¿realmente le sucede a los programadores competentes ?)

Answer 6

Como han mencionado otros, hacer una instrucción if en dos líneas sin llaves puede conducir a confusión:

if (a == b)
    DoSomething();
    DoSomethingElse(); <-- outside if statement

entonces lo coloco en una sola línea si puedo hacerlo sin dañar la legibilidad:

if (a == b) DoSomething();

y en todas las otras ocasiones uso llaves.

Los operadores ternarios son un poco diferentes. La mayoría de las veces los hago en una línea:

var c = (a == b) ? DoSomething() : DoSomethingElse();

pero a veces los enunciados tienen llamadas de función anidadas, o expresiones lambda que hacen que una declaración de una línea sea difícil de analizar visualmente, por lo que prefiero algo como esto:

var c = (a == b)
    ? AReallyReallyLongFunctionName()
    : AnotherReallyReallyLongFunctionOrStatement();

Aún más conciso que un bloque if / else pero fácil de ver qué está pasando.

Answer 7

Mi preferencia es ser coherente, por ejemplo, si usa corchetes en un bloque, use corchetes en todo, incluso con solo una afirmación:

if (cond1)
{
   SomeOperation();
   Another();
}
elseif (cond2)
{
   DoSomething();
}
else
{
   DoNothing();
   DoAnother();
}

Pero si solo tienes un montón de líneas de uno:

if (cond1)
    DoFirst();
elseif (cond2)
    DoSecond();
else
    DoElse();

Se ve más limpio (si no le molestan los nombres del método ficticio;) de esa manera, pero así soy yo.

Esto también se aplica a construcciones de bucle y similares:

foreach (var s as Something)
    if (s == someCondition)
        yield return SomeMethod(s);

También debería considerar que esta es una convención que podría ser más adecuada para .NET (observe que a Java le gusta tener su primer llavero en la misma línea que si).

Answer 8

No hay forma correcta o incorrecta de escribir la declaración anterior. Hay muchos estilos de codificación aceptados. Sin embargo, para mí, prefiero mantener el estilo de codificación consistente en todo el proyecto. es decir. Si el proyecto usa el estilo K & R, debe usar K & R.

Answer 9

Realmente no importa, siempre y cuando seas consecuente con eso.

Parece haber una tendencia a exigir igualdad en un solo enunciado, es decir, si hay corchetes en una rama, hay corchetes en todas partes. Los estándares de codificación del kernel de Linux, por ejemplo, lo ordenan.

Answer 10

Tiendo a estar de acuerdo con Joel Spolsky en ese artículo ( Making Wrong Code Look Wrong ) con el siguiente ejemplo de código:

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

Foo ahora es incondicional. ¡Que es realmente malo!

Siempre utilizo corchetes para las declaraciones de decisión. Ayuda a mantener el código y hace que el código sea menos propenso a errores.

Answer 11

Yo recomendaría siempre usar llaves, incluso cuando son opcionales. ¿Por qué? Toma este trozo de código C ++:

if (var == 1)
  doSomething();
doSomethingElse();

Ahora, aparece alguien que no está prestando suficiente atención y decide que algo adicional debe suceder si (var == 1), entonces lo hacen:

if (var == 1)
  doSomething();
  doSomethingExtra();
doSomethingElse();

Todavía está bellamente sangrado, pero no hará lo que se pretendía.

Al usar siempre llaves, es más probable que evites este tipo de error.

Answer 12

yo prefiero

if (cond)
   {
   //statement
   }

incluso con solo una declaración. Si ibas a escribir algo una vez, no tenías dudas de que funcionó, y nunca planeaste otro codificador que alguna vez haya visto ese código, sigue adelante y usa el formato que quieras. Pero, ¿qué te cuesta realmente el horquillado extra? Menos tiempo en el transcurso de un año de lo que lleva escribir esta publicación.

Sí, me gusta aplicar sangría al nivel del bloque, también.

Python es agradable porque la sangría define el bloque. La pregunta es discutible en un lenguaje como ese.

Answer 13

yo recomiendo

if(a==b)
{
    doSomething();
}

porque me resulta mucho más fácil hacerlo por adelantado que tratar de recordar agregar las llaves cuando agrego una segunda declaración a la condición de éxito ...

if(a==b)
    doSomething();
    doSomethingElse();

es muy diferente a

if(a==b)
{
    doSomething();
    doSomethingElse();
}

ver el artículo de Joel para más detalles

Answer 14

Personalmente, estoy de acuerdo con la explicación de McConnell de Code Complete.

Úsalos siempre que puedas. Mejoran la legibilidad de su código y eliminan las pocas y escasas confusiones que puedan ocurrir.

Sin embargo, hay una cosa que es más importante ... Consistencia. Cualquiera que sea el estilo que use, asegúrese de hacerlo siempre de la misma manera.

Comienza a escribir cosas como:

If A == true
   FunctA();

If B == "Test"
{
   FunctB();
}

Es probable que termine buscando un error extraño en el que el compilador no comprenda lo que estaba tratando de hacer y eso será difícil de encontrar.

Básicamente, encuentre el que se siente cómodo escribiendo cada vez y manténgalo. Sí creo en el uso de los delímetros de bloque (''{'', ''}'') tanto como sea posible es el camino a seguir.

No quiero comenzar una pregunta dentro de otra, pero hay algo relacionado con esto que quiero mencionar para que tus jugos mentales vayan. Una de las decisiones de usar los corchetes ha sido hecha. ¿Dónde colocas el soporte de apertura? En la misma línea que la declaración o debajo. Abrazaderas con sangría o no?

If A == false {
  //calls and whatnot
}
//or
If B == "BlaBla"
{
  //calls and whatnot
}
//or
If C == B
  {
  //calls and whatnot
  }

Por favor, no responda a esto ya que esta sería una nueva pregunta. Si veo un interés en esto, abriré una nueva pregunta, su opinión.

Answer 15

Utilizo llaves en cada afirmación si y solo si al menos una de ellas lo requiere.

Answer 16

Convenciones del código de Sun para el lenguaje de programación Java tiene esto que decir:

La clase de declaraciones if-else debe tener la siguiente forma:

if (condition) {
    statements;
}

if (condition) {
    statements;
} else {
    statements;
}

if (condition) {
    statements;
} else if (condition) {
    statements;
} else {
    statements;
}

Answer 17

En Perl, si está haciendo una prueba simple, en algún momento la escribirá de esta forma:

do_something if condition;

do_something unless condition;

Lo cual puede ser realmente útil para verificar los argumentos al inicio de una subrutina.

sub test{
  my($self,@args) = @_;

  return undef unless defined $self;

  # rest of code goes here

}

Answer 18

Tiendo a usar aparatos todo el tiempo. Puede obtener algunos errores sutiles donde comenzó con algo como:

if(something)
 DoOneThing();
else
  DoItDifferently();

y luego decide agregar otra operación a la cláusula else y olvida envolverla con llaves:

if(something)
 DoOneThing();
else
  DoItDifferently();
  AlwaysGetsCalled(); 

Siempre se llamará a AlwaysGetsCalled() , y si estás sentado allí a las 3 de la madrugada preguntándote por qué tu código se comporta de manera extraña, algo así podría eludirte por bastante tiempo. Por esta razón, siempre uso llaves.

Answer 19

La regla de oro es que, al trabajar en un proyecto existente, siga esos estándares de codificación.

Cuando estoy en casa, tengo dos formas.

El primero es la línea única:

if (condition) doThis();

y el segundo es para líneas múltiples:

if (condition) {
   doThis();
}

Answer 20

Solía ​​seguir la línea "usar las llaves siempre" como un apparatchik. Sin embargo, he modificado mi estilo para permitir omitirlos en expresiones condicionales de una sola línea:

if(!ok)return;

Para cualquier escenario de varias instancias, aunque sigo opinando que los frenos deben ser obligatorios:

if(!ok){

    do();

    that();

    thing();
}