programar - javascript pdf

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

Question

Una vez escuché que dejar las llaves en 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 una buena idea para rodear todas las declaraciones dentro de llaves en JavaScript?

Estoy preguntando, porque todos parecen hacerlo.

Answer 1

No

Pero son recomendados. Si alguna vez expandes la declaración, los necesitarás.

Esto es perfectamente válido

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

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

Esta misma práctica se sigue en todos los lenguajes de estilo de sintaxis C con arriostramiento. C, C ++, Java, incluso PHP son compatibles con una sentencia de línea sin llaves. Tienes que darte cuenta de que solo estás guardando dos personajes y con los estilos de arriostramiento de algunas personas ni siquiera estás guardando una línea. Prefiero un estilo de refuerzo completo (como el siguiente) por lo que tiende a ser un poco más largo. El intercambio se cumple muy bien con el hecho de que tiene legibilidad de código extremadamente clara.

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

Answer 2

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

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

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

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

arregló esa materia. Hay miles de ejemplos donde aparentemente funciona sin llaves, pero en este caso definitivamente no.

Las personas que tienden a poner más de un enunciado en una línea definitivamente siempre deben usar aparatos ortopédicos, por supuesto, porque cosas como

if (condition)
    do something; do something else;

son difíciles de encontrar

Answer 3

¡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 esperaba!

Answer 4

Actualmente estoy trabajando en un minificador. Incluso ahora lo controlo en dos grandes scripts. Experimentalmente descubrí: puedes quitar las llaves detrás para, si, else, while, function * si las llaves no incluyen '';'', ''return'', ''for'', ''if'', ''else'', ''while'', ''do'', ''function''. Irrespectos saltos de línea.

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

Por supuesto, debe reemplazar el corchete de cierre con un punto y coma si no está seguido por otro corsé 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.

Answer 5

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;

Por lo tanto, esto también puede arrojar 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 (?)

Answer 6

El nivel de indentación inicial de una instrucción debe ser igual al número de llaves abiertas que se encuentran encima. (excluyendo llaves citadas o comentadas o unas en directivas de preprocesador)

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

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

en lugar de

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

Si estuviese escribiendo un editor, haría que su botón de formato automático chupara la barra hasta la misma línea que foo, y lo haría insertar llaves en la barra si presiona regresar antes de esta manera:

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

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

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

Answer 7

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

Las instrucciones sin código funcionan en la mayoría de los navegadores, sin embargo, probé que los métodos sin soporte de hecho no funcionan en ningún navegador.

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

function foo()
   return bar;

Answer 8

Es una cuestión de estilo, pero las llaves son buenas para evitar que los demás puedan colgar .

Answer 9

Esta es la razón por la que se recomienda

Digamos que escribo

if(someVal)
    alert("True");

Luego viene el siguiente desarrollador y dice: "Oh, necesito hacer otra cosa", entonces escriben

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

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

Answer 10

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

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

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

Answer 11

Hay un aspecto de legibilidad, en el sentido de que cuando tienes declaraciones compuestas puede ser muy confuso. (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); //On on IF
alert(b); //Always

//Indenting is bad
if (a===true)
  alert(a); //On 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
} 

(El pensamiento es que si siempre tienes los corchetes entonces sabes insertar otras declaraciones dentro de ese bloque).

Answer 12

Hay una forma de lograr llaves múltiples no rizadas si declaraciones ... (¡qué inglés!) Pero es un poco tedioso:

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


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

Answer 13

La pregunta pregunta acerca de las declaraciones en una línea. Sin embargo, los numerosos ejemplos brindados muestran razones para no omitir llaves basadas en declaraciones de líneas múltiples. Es completamente seguro no usar corchetes en una línea, si ese es el estilo de codificación que prefiera.

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 declaraciones múltiples 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 declaraciones ''if''. Como resultado, el uso de corchetes en una sola declaración de condición de condición requeriría 3 líneas. Me gusta esto:

 if (condition) {
   statement;
 }

Es preferible usar una sentencia if de una línea porque utiliza menos espacio vertical y el código es más compacto.

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

Answer 14

No hay una 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.

Answer 15

Siempre encontré eso

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) que

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

pero supongo que se trata de un estilo de codificación

Answer 16

Solo me gustaría notar que también puedes dejar las llaves de otra cosa. Como se ve en este artículo de John Resig .

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

Answer 17

Absolutamente sí

Olvídate de "es una preferencia personal", "el código funcionará bien", "ha funcionado bien para mí", "es más legible", yada BS.

Argumento: "Es preferencia personal"

No, no es. A menos que seas un equipo de un solo hombre en 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 funcionará bien"

Lo mismo ocurre con el código de spaghetti! ¿Significa que está bien crearlo?

Argumento: "ha funcionado bien para mí"

En mi carrera, he visto tantos errores creados por este problema. Probablemente no recuerde cuántas veces comentó ''DoSomething()'' y desconcertado por qué se llama ''SomethingElse()'' :

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 pasar de todo el registro para que ejecute find & replace "Console.println" => //"Console.println" :

if (condition) 
   Console.println("something");
SomethingElse();

Ver 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 ti (¡ojalá no seas el peor en el 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 el siguiente después de haber sido probado con diferentes navegadores / entornos / casos de uso o se agregan nuevas características:

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 quien notó el error en el ejemplo anterior