¿Son necesarias las llaves en las declaraciones de una línea en JavaScript?

Una vez escuché que dejar las llaves en las declaraciones de una línea podría ser dañino en JavaScript. Ya no recuerdo el razonamiento y una búsqueda en Google no ayudó mucho.

¿Hay algo que haga que sea una buena idea rodear todas las declaraciones entre llaves en JavaScript?

Estoy preguntando, porque todos parecen hacerlo.

No

Pero son recomendables. Si alguna vez expande la declaración, los necesitará.

Esto es perfectamente valido

if (cond) 
    alert("Condition met!")
else
    alert("Condition not met!")

Sin embargo, es muy recomendable que siempre use llaves, ya que si usted (u otra persona) expande la declaración, será necesario.

Esta misma práctica sigue en todos los lenguajes de estilo de sintaxis C con arriostramiento. C, C ++, Java e incluso PHP admiten una declaración de línea sin llaves. Debes darte cuenta de que solo estás guardando dos caracteres y con los estilos de refuerzo de algunas personas ni siquiera estás guardando una línea. Prefiero un estilo de llave completa (como el siguiente), por lo que tiende a ser un poco más largo. La compensación se cumple muy bien con el hecho de que tiene una legibilidad de código extremadamente clara.

if (cond) 
{
    alert("Condition met!")
}
else
{
    alert("Condition not met!")
}

Hay un aspecto de legibilidad: cuando tienes declaraciones compuestas puede ser muy confuso. La sangría ayuda pero no significa nada para el compilador / intérprete.

var a;
var b;
var c;

//Indenting is clear
if (a===true)
  alert(a); //Only on IF
alert(b); //Always

//Indenting is bad
if (a===true)
  alert(a); //Only on IF
  alert(b); //Always but expected?

//Nested indenting is clear
if (a===true)
  if (b===true)
    alert(a); //Only on if-if
alert (b); //Always

//Nested indenting is misleading
if (a===true)
  if (b===true)
    alert(a); //Only on if-if
  alert (b); //Always but expected as part of first if?

//Compound line is misleading
//b will always alert, but suggests it's part of if
if (a===true) alert(a);alert(b); 
else alert(c); //Error, else isn't attached

Y luego hay un aspecto de extensibilidad:

//Problematic
if (a===true)
  alert(a);
  alert(b); //We're assuming this will happen with the if but it'll happen always
else       //This else is not connected to an if anymore - error
  alert(c);

//Obvious
if (a===true) {
  alert(a); //on if
  alert(b); //on if
} else {
  alert(c); //on !if
} 

Se piensa que si siempre tiene los corchetes, entonces sabe insertar otras declaraciones dentro de ese bloque.

La pregunta se refiere a declaraciones en una línea. Sin embargo, los muchos ejemplos proporcionados muestran razones para no omitir llaves basadas en declaraciones de varias líneas. Es completamente seguro no usar corchetes en una línea, si ese es el estilo de codificación que prefiere.

Por ejemplo, la pregunta pregunta si esto está bien:

 if (condition) statement;

No pregunta si esto está bien:

 if (condition)
   statement;

Creo que es preferible dejar los corchetes porque hace que el código sea más legible con una sintaxis menos superflua.

Mi estilo de codificación es nunca usar corchetes a menos que el código sea un bloque. Y nunca usar múltiples declaraciones en una sola línea (separadas por punto y coma). Encuentro esto fácil de leer y claro y nunca tengo problemas de alcance en las declaraciones 'if'. Como resultado, el uso de corchetes en una sola declaración de condición requeriría 3 líneas. Me gusta esto:

 if (condition) {
   statement;
 }

Usar una línea si la declaración es preferible porque usa menos espacio vertical y el código es más compacto.

No forzaría a otros a usar este método, pero funciona para mí y no podría estar más en desacuerdo con los ejemplos proporcionados sobre cómo dejar los corchetes conduce a errores de codificación / alcance.

Técnicamente no, pero por lo demás absolutamente ¡Sí!

Olvídate de "Es preferencia personal", "el código funcionará bien", "me ha funcionado bien", "es más legible" yada yada BS. Esto podría conducir fácilmente a problemas muy serios si comete un error y créame, es muy fácil cometer un error cuando está codificando (¿No cree ?, vea el famoso error de falla de Apple ).

Argumento: "Es preferencia personal"

No, no es. A menos que sea un equipo de un solo hombre que se vaya a Marte, no. La mayoría de las veces habrá otras personas leyendo / modificando su código. En cualquier equipo de codificación serio, esta será la forma recomendada, por lo que no es una 'preferencia personal'.

Argumento: "el código se ejecutará bien"

¡También el código de espagueti! ¿Significa que está bien crearlo?

Argumento: "ha funcionado bien para mí"

En mi carrera he visto tantos errores creados debido a este problema. Probablemente no recuerdes cuántas veces has comentado 'DoSomething()'y desconcertado por qué 'SomethingElse()'se llama:

if (condition) 
    DoSomething();
SomethingElse();

O agregó 'SomethingMore' y no notó que no se llamará (aunque la sangría implica lo contrario):

if (condition)
  DoSomething();
  SomethingMore();

Aquí hay un ejemplo de la vida real que tuve. Alguien quería desactivar todos los registros para ejecutar find & replace "console.log"=> //"console.log":

if (condition) 
   console.log("something");
SomethingElse();

¿Ves el problema?

Incluso si piensas, "estos son tan triviales, nunca haría eso"; recuerda que siempre habrá un miembro del equipo con habilidades de programación inferiores a las tuyas (¡ojalá no seas el peor del equipo!)

Argumento: "es más legible"

Si he aprendido algo sobre programación, es que las cosas simples se vuelven muy complejas muy rápidamente. Es muy común que esto:

if (condition) 
    DoSomething();

se convierte en lo siguiente después de que se haya probado con diferentes navegadores / entornos / casos de uso o se hayan agregado nuevas funciones:

if (a != null)
   if (condition) 
      DoSomething();
   else
      DoSomethingElse(); 
      DoSomethingMore();
else 
    if (b == null)
         alert("error b");
    else 
         alert("error a");

Y compáralo con esto:

 if (a != null) {
    if (condition) { 
       DoSomething();
    }
    else {
       DoSomethingElse();
       DoSomethingMore();
    }
 } else if (b == null) {
    alert("error b");
 } else {
    alert("error a");
 }

PD: Los puntos de bonificación van a quienes notaron el error en el ejemplo anterior.

¡No hay problema de mantenimiento!

El problema con todos ustedes es que ponen punto y coma en todas partes. No necesita llaves para múltiples declaraciones. Si desea agregar una declaración, solo use comas.

if (a > 1)
 alert("foo"),
 alert("bar"),
 alert("lorem"),
 alert("ipsum");
else
 alert("blah");

¡Este es un código válido que se ejecutará como esperabas!

No hay ninguna razón de programación para usar las llaves en declaraciones de una línea.

Esto solo se reduce a las preferencias y legibilidad de los codificadores.

Tu código no se romperá por eso.

Además del motivo mencionado por @Josh K (que también se aplica a Java, C, etc.), un problema especial en JavaScript es la inserción automática de punto y coma . Del ejemplo de Wikipedia:

return
a + b;

// Returns undefined. Treated as:
//   return;
//   a + b;

Entonces, esto también puede producir resultados inesperados, si se usa así:

if (x)
   return
   a + b;

No es mucho mejor escribir

if (x) {
   return
   a + b;
}

pero tal vez aquí el error es un poco más fácil de detectar (?)

Es una cuestión de estilo, pero las llaves son buenas para evitar posibles colgantes de otras personas .

Hay muchas buenas respuestas, por lo que no repetiré, excepto para decir mi "regla" cuando se pueden omitir los aparatos ortopédicos: en condiciones que "devuelven" o "arrojan" (por ejemplo) como su única declaración . En este caso, el control de flujo ya está claro que está terminando:

Incluso el "mal caso" puede identificarse rápidamente (y repararse) debido al control de flujo de terminación. Esta "regla" de concepto / estructura también se aplica a varios idiomas.

if (x)
    return y;
    always();

Por supuesto, esta es también la razón por la que uno podría usar un linter ...

Aquí es por qué se recomienda

Digamos que escribo

if(someVal)
    alert("True");

Luego viene el próximo desarrollador y dice "Oh, necesito hacer otra cosa", y escriben

if(someVal)
    alert("True");
    alert("AlsoTrue");

Ahora, como puede ver, "AlsoTrue" siempre será cierto, porque el primer desarrollador no usó llaves.

Actualmente estoy trabajando en un minificador. Incluso ahora lo reviso en dos scripts enormes. Experimentalmente lo descubrí: puede quitar las llaves detrás de, si, de lo contrario, mientras, funciona * si las llaves no incluyen ';', 'return', 'for', 'if', 'else', 'while', 'do', 'function'. Saltos de línea independientes.

function a(b){if(c){d}else{e}} //ok  
function a(b){if(c)d;else e}   //ok

Por supuesto, debe reemplazar la llave de cierre con un punto y coma si no le sigue otra llave de cierre.

Una función no debe terminar en una coma.

var a,b=function()c;  //ok *but not in Chrome
var b=function()c,a;  //error  

Probado en Chrome y FF.

Siempre encontré que

if(valid) return;

es más fácil para mi ojo que

if(valid) {
  return;
}

también condicional como

(valid) ? ifTrue() : ifFalse();

son más fáciles de leer (mi opinión personal) en lugar de

if(valid) {
  ifTrue();
} else {
  ifFalse();
}

pero supongo que todo se reduce al estilo de codificación

No responde la pregunta directamente, pero a continuación hay una breve sintaxis sobre la condición if en una línea

Ex:

var i=true;
if(i){
  dosomething();
}

Se puede escribir así:

var i=true;
i && dosomething();

Hay muchos problemas en javascript. Eche un vistazo al arquitecto de JavaScript Douglas Crockford hablando de ello. La declaración if parece estar bien, pero la declaración return puede presentar un problema.

return
{
    ok:false;
}
//silent error (return undefined)

return{
    ok:true;
}
//works well in javascript

Encontré esta respuesta buscando una experiencia similar, así que decidí responderla con mi experiencia.

Las declaraciones sin corchetes funcionan en la mayoría de los navegadores, sin embargo, probé que los métodos sin corchetes de hecho no funcionan en algunos navegadores.

A partir del 26 de febrero de 2018, esta declaración funciona en Pale Moon, pero no en Google Chrome.

function foo()
   return bar;

El nivel inicial de sangría de una declaración debe ser igual al número de llaves abiertas por encima de ella. (excluyendo llaves o comillas citadas o comentadas en las directivas de preprocesador)

De lo contrario, K&R sería un buen estilo de sangría. Para arreglar su estilo, recomiendo colocar declaraciones if cortas y simples en una línea.

if (foo) bar();    // I like this. It's also consistent with Python FWIW

en vez de

if (foo)
   bar();   // not so good

Si estuviera escribiendo un editor, haría que su botón de formato automático succione la barra hasta la misma línea que foo, y lo haría insertar llaves alrededor de la barra si presiona Intro antes de esto:

if (foo) {
  bar();    // better
}

Entonces es fácil y consistente agregar nuevas declaraciones encima o debajo de la barra dentro del cuerpo de la declaración if

if (foo) {
  bar();    // consistent
  baz();    // easy to read and maintain
}

¡A veces parecen ser necesarios! No podía creerlo, pero ayer se me ocurrió en una sesión de Firebug (reciente Firefox 22.0) que

if (! my.condition.key)
    do something;

ejecutado hacer algo a pesar de que my.condition.key era cierto . Agregar llaves:

if (! my.condition.var) {
    do something;
}

Arreglado ese asunto. Hay miles de ejemplos en los que aparentemente funciona sin las llaves, pero en este caso definitivamente no lo hizo.

Las personas que tienden a poner más de una declaración en una línea siempre deben usar llaves, por supuesto, porque cosas como

if (condition)
    do something; do something else;

Son difíciles de encontrar.

Solo me gustaría señalar que también puede dejar las llaves fuera de lo demás. Como se ve en este artículo de John Resig's .

if(2 == 1){
    if(1 == 2){
        console.log("We will never get here")
    }
} else 
    console.log("We will get here")

Hay una manera de lograr llaves de línea múltiple no rizadas si declaraciones ... (Wow qué inglés ...) pero es un poco tedio:

if(true)
   funcName();
else
   return null;


function funcName(){
  //Do Stuff Here...
}