¿Por qué los resultados varían en función de la colocación del corsé?

Question

He leído esto article, donde se muestra un ejemplo. Explique por qué los fragmentos de código a continuación arrojan resultados diferentes debido a cambios en la colocación de las llaves.

Ejemplo con una llave de apertura { en una nueva línea.

function test() 
{ 
    return 
    { /* <----curly brace in new line */ 
    javascript: "fantastic" 
    }; 
} 

var r = test(); 
try { 
    alert(r.javascript); // does this work...? 
} catch (e) { 
    alert('no - it broke: ' + typeof r); 
} 

test() vuelve undefined.

Ejemplo con una llave de apertura { en la misma línea que return.

function test() 
{ 
    return { /* <----inline curly brace */ 
    javascript : "fantastic" 
    }; 
} 

var r = test(); 
try { 
    alert(r.javascript); // does this work...? 
} catch (e) { 
    alert('no - it broke: ' + typeof r); 
} 

test() devuelve un objeto.

Aquí está el ejemplo en vivo beware of curly braces.

Answer 1

Esa es una de las trampas de javascript: inserción de punto y coma automática. Líneas que no terminan con un punto y coma, pero podría ser el final de una instrucción se terminan de forma automática, por lo que su primer ejemplo se ve efectivamente así:

function test() 
{ 
    return; // <- notice the inserted semicolon 
    { 
    javascript : "fantastic" 
    }; 
} 

Véase también http://javascript.crockford.com/code.html

En el segundo ejemplo que regrese un objeto (construido por las llaves) con la propiedad javascript y su valor de fantástico, efectivamente lo mismo que esto:

function test() { 
    var myObject = new Object(); 
    myObject.javascript = "fantastic"; 
    return myObject; 
} 

Answer 2

Es porque Javascript a lo más a menudo pone ";" al final de cada línea, tan básicamente cuando tienes devolución {en la misma línea, el motor de JavaScript ve que habrá algo más, y cuando está en una nueva línea cree que olvidaste poner ";" y se lo pone por ti.

Answer 3

El problema es, de hecho, inyección de punto y coma como se describió anteriormente. Acabo de leer una buena publicación en el blog sobre este tema. Explica este problema y mucho más sobre javascript. También contiene algunas buenas referencias. Puede leerlo here

Answer 4

Las llaves aquí indican la construcción de un nuevo objeto. Así, su código es equivalente a:

function test() { 
    var a = { javascript : "fantastic" }; 
    return a; 
} 

que trabaja mientras que si se escribe:

function test() { 
    var a = { javascript : "fantastic" }; 
    return; // ; is automatically inserted 
     a; 
} 

ya no funciona.

Answer 5

JavaScript no requiere punto y coma al final de las instrucciones, pero el inconveniente es que tiene que adivinar dónde están los puntos y comas. La mayoría de las veces esto no es un problema, pero a veces inventa un punto y coma en el que no tenía intención de hacerlo.

Un ejemplo de mi post sobre esto (Javascript – almost not line based):

Si formatea el código como el siguiente:

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

entonces se interpreta así:

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

El return statement toma su forma sin parámetros, y el argumento se convierte en una declaración propia.

Lo mismo ocurre con su código. La función se interpreta como:

function test() 
{ 
    return; 
    { 
    javascript : "fantastic" 
    }; 
} 

Answer 6

yo personalmente prefiero el estilo Allman para facilitar la lectura (vs K & estilo R).

En lugar de ...

function test() { 
    return { 
    javascript : "fantastic" 
    }; 
} 

me gusta ...

function test() 
{ 
    var obj = 
    { 
    javascript : "fantastic" 
    }; 

    return obj; 
} 

Pero esta es una solución temporal. Sin embargo, puedo vivir con eso.

Answer 7

Excluyendo el estándar return; reason.

Los soportes en las nuevas líneas son MALOS HABITOS tomados de otros laguanges C-like donde este es un estándar. Si la legibilidad es la razón, entonces también podemos proporcionar esto mediante un nombre de variable escrito en su propia etiqueta, pero no lo estamos haciendo, ¿verdad? Los nuevos paréntesis de línea SON MALOS HABITOS, y también, por ejemplo en google chrome, se muestran como errores de debugger.

Cuando trabajas con equipos, existe un 99% de posibilidades de que la nueva línea { esté prohibida debido a un IDE que automáticamente estandarizará el código. Como WebStorm/VisualStudio.

Cuando miras el github, verás que el más popular es { en la misma línea. (Si encuentra otra versión, proporcione un ejemplo)

Además, cada línea de código debe tener un significado en los idiomas que se interpretan principalmente como no compilados. ¿Cómo podría "explicar" interpretar una línea que comienza con:

{ 

? ¿es el comienzo del bloque? Supongo que dijiste yes. Ahora dime cuánto puede decir acerca de:

function foo() { 

(por supuesto que estamos contando acerca de los archivos no miniaturizada para que también estamos ahorrando unos cuantos B de memoria)

no me gusta forzar inteprer mirar adelante/atrás. Debe leer la línea y hacer algo que esté en línea, no en dos líneas.

Estoy seguro de que ECMA 202X lo agregará como ESTÁNDAR. Realmente no me importa si alguien lo está haciendo en sus proyectos, pero como persona que trabaja principalmente con EQUIPOS de programadores no aceptaría este tipo de código hipsterizing.

El siguiente caso sería agregar cómo CoffeScript/TypeScript y otros dialectos. Estas herramientas le devolverán el código con { con la misma línea. ¿Por qué? Porque es así como debería hacerse.

EDIT:

I Went más profunda con mi investigación sobre el tema, y ​​me he puesto en contacto equipo ECMA sí mismos

Hola, estoy bastante seguro de que probablemente no llegue answere sobre eso. Pero me gustaría saber qué prefiere el equipo de ECMA. ¿Que los corchetes en javascript estarían escritos en la misma línea o en una nueva línea? (Ejemplo excluyendo con la "vuelta"; DECLARACIÓN e inserción punto y coma automática Estoy escribiendo mi tesis, y su mensaje serían tan útiles como han señalado algunos profesionales DE VISTA Gracias por el trabajo impresionante

como answere I... conseguir esto:.

TC39 no toma ninguna posición oficial de cuestiones tales como estilista este estoy seguro de que entre los miembros delegados que participan en el TC39 que puedes encontrar diversas opciones de formato de código sin embargo. , I sospecho que la mayoría preferiría usar puntos y comas explícitos en lugar de confiando en ASI.

editar: Sé que algunas personas se sienten frustradas por el hecho de que están haciendo algo mal, pero dar un "-1" no es el mejor enfoque. La sección de comentarios está abierta, así que comparta su opinión con otros.