¿Cuál es el estilo preferido para declaraciones de decisión y acción únicas?

Question

En el caso de lenguajes que soportan decisión y acción única sin corchetes, como el siguiente ejemplo:

if (var == true)
    doSomething();

¿Cuál es la forma preferida de escribir esto?¿Deben usarse siempre corchetes o su uso debe dejarse 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

Realmente no hay una respuesta correcta.Para esto sirven los estándares de codificación dentro de la empresa.Si puede mantenerlo coherente 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 2

recomiendo

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

porque me resulta mucho más fácil hacerlo por adelantado que intentar 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 mas detalles

Answer 3

Tiendo a usar brackets en todo momento.Puede obtener algunos errores sutiles cuando comenzó con algo como:

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

y luego decide agregar otra operación a la else cláusula y olvídate de envolverla entre llaves:

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

AlwaysGetsCalled() Siempre recibirás una llamada, y si estás sentado allí a las 3 a.m. preguntándote por qué tu código se comporta de manera extraña, algo así podría eludirte durante bastante tiempo.Sólo por esta razón siempre uso brackets.

Answer 4

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

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

Pero si solo tienes un montón de frases:

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

Se ve más limpio (si no te importan los nombres de los métodos ficticios;) de esa manera, pero soy solo yo.

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

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

También debe considerar que esta es una convención que podría ser más adecuada para .NET (tenga en cuenta que a Java peepz le gusta tener su primera llave en la misma línea que if).

Answer 5

Atribuya esto a la falta de experiencia, pero durante mis siete años como mono codificador he nunca De hecho, he visto a alguien cometer el error de no agregar llaves al agregar código a un bloque que no tiene llaves.Eso es precisamente cero veces.

Y antes de que lleguen los bromistas, no, la razón no fue "todo el mundo siempre usa frenillos".

Entonces, una pregunta honesta: realmente me gustaría recibir respuestas reales en lugar de solo votos negativos:¿Eso realmente sucede alguna vez?

(Editar:He escuchado suficientes historias de terror sobre subcontratación para aclarar un poco:¿Alguna vez le pasó realmente a programadores competentes?)

Answer 6

Realmente no importa, siempre y cuando seas coherente con ello.

Parece haber una tendencia a exigir igualdad dentro de una sola declaración, 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 exigen.

Answer 7

Yo recomendaría firmemente siempre usando llaves, incluso cuando son opcionales.¿Por qué?Tome este fragmento de código C++:

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

Ahora, aparece alguien que realmente no está prestando suficiente atención y decide que es necesario que suceda algo adicional si (var == 1), entonces hace esto:

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

Todo todavía tiene una hermosa sangría, pero no hará lo que se pretendía.

Si utiliza siempre llaves, es más probable que evite este tipo de error.

Answer 8

Personalmente estoy del lado de 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 pueden ocurrir.

Pero hay una cosa que es más importante... la coherencia.Sea cual sea el estilo que uses, asegúrate de hacerlo siempre de la misma manera.

Empieza a escribir cosas como:

If A == true
   FunctA();

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

Seguramente terminarás buscando un error extraño en el que el compilador no entenderá lo que estabas intentando hacer y será difícil de encontrar.

Básicamente, encuentre aquel con el que se sienta cómodo escribiendo cada vez y cúmplalo.Creo que usar los delimitadores de bloque ('{', '}') tanto como sea posible es el camino a seguir.

No quiero empezar una pregunta dentro de otra, pero hay algo relacionado con esto que quiero mencionar para activar tu mente.Una vez se ha tomado la decisión de utilizar los corchetes.¿Dónde pones el soporte de apertura?En la misma línea que la declaración o debajo.¿Corchetes sangrados 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 sería una pregunta nueva.Si veo interés en esto, abriré una nueva pregunta con su aporte.

Answer 9

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

En ese caso, me aseguro de que quede claro que es una declaración única manteniendo todo en una línea, así:

if (aString) free(aString);

Answer 10

No existe una forma correcta o incorrecta de escribir la declaración anterior.Hay muchas codificaciones aceptadas. estilos.Sin embargo, en mi caso, prefiero mantener el estilo de codificación constante durante todo el proyecto.es decir.Si el proyecto utiliza el estilo K&R, debe utilizar K&R.

Answer 11

Ruby obvia muy bien un tema en la discusión.El estándar para una sola línea 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 sola línea, pero le obliga a reorganizar la declaración si pasa de una sola línea a varias líneas.

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

Answer 12

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

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

así que lo coloco en una sola línea si puedo hacerlo sin perjudicar la legibilidad:

if (a == b) DoSomething();

y el resto del tiempo uso brackets.

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

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

Pero a veces las declaraciones tienen llamadas de funciones 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 es fácil ver lo que está pasando.

Answer 13

del sol Convenciones de código para el lenguaje de programación Java tiene este decir:

La clase de declaraciones if-else debe tener el siguiente formulario:

if (condition) {
    statements;
}

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

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

Answer 14

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

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

Answer 15

yo prefiero

if (cond)
   {
   //statement
   }

incluso con una sola declaración.Si iba a escribir algo una vez, no tenía dudas de que funcionaba y nunca planeó que otro codificador mirara ese código, continúe y use el formato que desee.Pero, ¿cuánto te cuesta realmente el bracketing extra?Menos tiempo en el transcurso de un año del que se necesita para escribir esta publicación.

Sí, también me gusta sangrar mis corchetes al nivel del bloque.

Python es bueno porque la sangría define el bloque.La cuestión es discutible en un lenguaje como ese.

Answer 16

Tiendo a estar de acuerdo con Joel Spolsky en eso con ese artículo (Hacer que el código incorrecto parezca incorrecto) con el siguiente ejemplo de código:

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

Foo ahora es incondicional.¡Lo cual es realmente malo!

Siempre uso corchetes para las declaraciones de decisión.Ayuda al mantenimiento del código y hace que el código sea menos propenso a errores.

Answer 17

Utilizo llaves alrededor de cada declaración si y sólo si al menos una de ellas lo requiere.

Answer 18

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

do_something if condition;

do_something unless condition;

Lo cual puede resultar realmente útil para comprobar los argumentos al inicio de una subrutina.

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

  return undef unless defined $self;

  # rest of code goes here

}

Answer 19

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

Cuando estoy en casa, tengo dos formularios.

La primera es la línea única:

if (condition) doThis();

y el segundo es para varias líneas:

if (condition) {
   doThis();
}

Answer 20

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

if(!ok)return;

Para cualquier escenario de múltiples declaraciones, sigo opinando que las llaves deberían ser obligatorias:

if(!ok){

    do();

    that();

    thing();
}