¿El estilo de bloque es realmente tan importante?

Question

que acabo de ver un video de la presentación de Douglas Crockford sobre su libro de 2009 JavaScript: las partes buenas.

En el video, que explica que el siguiente bloque es peligrosa porque produce errores silenciosos:

return 
{ 
    ok: false 
}; 

Y que en realidad debería escribirse así (haciendo hincapié en que, aunque aparentemente idéntica la diferencia de comportamiento es crucial) :

return { 
    ok: false 
}; 

puedes ver sus comentarios alrededor de 32 minutos en el vídeo aquí: http://www.youtube.com/watch?v=hQVTIJBZook&feature=player_embedded#!&start=1920

No he escuchado esto antes, y me preguntaba si esta regla todavía se aplica o si este requisito en sintaxis ha sido superado por los desarrollos de JavaScript desde que se hizo esta declaración.

Me pareció muy interesante ya que no he estado escribiendo mi código de esta manera, y quería comprobar que esta información no estaba fuera de fecha.

Answer 1

El error en silencio es que se devuelve undefined!

puntos y comas son opcionales en JavaScript, y por lo tanto

return 
{ 
    ok: false 
}; 

se analiza como si se tratara de

return; // Leaves function straight away 
{ 
    ok: false 
}; 

JSLint reconocerán dichos patrones y advertir acerca de ellos:

pelusa advertencia: fin de línea inesperado; es ambigua si estas líneas son parte de la misma declaración

advertencia pelusa: falta punto y coma

advertencia pelusa: código inalcanzable

advertencia pelusa: bloque de sentido; las llaves no tienen impacto

Esto se ha discutido en SO en la pregunta "Strangest language feature".

Answer 2

Javascript insertará un punto y coma después de la vuelta, ya que "parece que falta".

Lo que sigue es un bloque de {OK: false} que no tiene ningún efecto.

lo que es un error en la especificación JavaScript ..

Mi recomendación es ejecutado JSLint cada vez que pueda, y configurarlo para permitir su estilo cuando es diferente de Crockford.

Answer 3

La regla sigue siendo válida.

Debido a que el lenguaje inserta automáticamente "perdido" punto y coma, el primer fragmento se interpreta como: se devuelve

return; 

{ 
    ok: false 
}; 

es decir, undefined. Si de alguna manera se permitiera que el código corriera más allá de la instrucción return, se crearía un objeto, pero no se le asignaría nada útil (una variable).

Answer 4

Este es un problema muy real. Volver involuntariamente un nulo definitivamente puede hacer cosas malas en tu código.

Answer 5

La regla se aplica hoy también, y es una de las "partes malas". El primer fragmento de código hará que la función devuelva undefined.

ver mi otra respuesta sobre este tema: Semicolon in C++?

Answer 6

Javascript es "amigable" lo suficiente como para suponer un punto y coma en los saltos de línea en algunos casos. De hecho, me escribió una entrada de blog sobre que hace un tiempo:

Javascript – almost not line based

La parte de la instrucción de retorno va:

Sin embargo, hay algunas cosas que no se puede hacer. Si, por ejemplo, pone un salto de línea entre la palabra clave return y su argumento, de repente tiene un significado diferente . Si formatea el código así:

function getAnswer() { 
    var answer = 42; 
    return 
    answer; 
} 

entonces se interpreta así:

function getAnswer() { 
    var answer = 42; 
    return; 
    answer; 
} 

La instrucción de retorno, que toma su forma sin parámetros, y el argumento se convierte en una declaración propia.

Answer 7

Preguntándose por qué la gente decide hacer cosas opcionales le costará casi nada agregar un punto y coma. Pero depurar esta situación puede llevar mucho tiempo.

En términos más generales, ¿por qué el diseñador de lenguaje siguió pensando que el código debería curarse por error del usuario? Si la gente comete un error, debe advertirse. De lo contrario, te meterás en problemas más adelante y más tarde.

Y sabemos que cuanto más tarde descubras el error, más caro será.