¿Hay algún otro idioma que no sea JavaScript que tenga una diferencia entre las ubicaciones de inicio de llaves (la misma línea y la siguiente)?

Question

Hoy, mientras estaba leyendo aleatoriamente los patrones de JavaScript del libro de O'Reilly, encontré una cosa interesante (página 27 para referencia).

En Javascript, en algunos casos, existe una diferencia si la ubicación de inicio de la llave es diferente.

function test_function1() { 
    return 
    { 
     name: 'rajat' 
    }; 
} 

var obj = test_function1(); 
alert(obj); //Shows "undefined" 

Mientras

function test_function2() { 
    return { 
     name: 'rajat' 
    }; 
} 

var obj = test_function2(); 
alert(obj); //Shows object 

JSfiddle Demo

¿Hay alguna otra lengua por ahí tiene este tipo de comportamiento? Si es así, entonces tendría que cambiar mi hábito con seguridad ... :)

Me preocupan principalmente PHP, C, C++, Java y ruby.

Answer 1

Cualquier lenguaje que no dependa de punto y coma (pero en cambio en líneas nuevas) para delimitar las declaraciones potencialmente lo permite. Considere Python:

>>> def foo(): 
... return 
... { 1: 2 } 
... 
>>> def bar(): 
... return { 1: 2 } 
... 
>>> foo() 
>>> bar() 
{1: 2} 

Usted puede ser capaz de construir un caso similar en Visual Basic pero fuera de la parte superior de mi cabeza no puedo encontrar la manera de VB porque es bastante restrictivo en donde los valores pueden ser metido. Sin embargo, el siguiente debería funcionar, a menos que el analizador estático se queja sobre el código inalcanzable:

Try 
    Throw New Exception() 
Catch ex As Exception 
    Throw ex.GetBaseException() 
End Try 

' versus 

Try 
    Throw New Exception() 
Catch ex As Exception 
    Throw 
    ex.GetBaseException() 
End Try 

De las lenguas que usted ha mencionado, Rubí tiene la misma propiedad. PHP, C, C++ y Java no simplemente porque descartan la nueva línea como espacios en blanco, y requieren punto y coma para delimitar las declaraciones.

Aquí está el código equivalente a partir del ejemplo de Python en Ruby:

>> def foo 
>> return { 1 => 2 } 
>> end 
=> nil 
>> def bar 
>> return 
>> { 1 => 2 } 
>> end 
=> nil 
>> foo 
=> {1=>2} 
>> bar 
=> nil 

Answer 2

El intérprete de JavaScript agrega automáticamente un ; al final de cada línea si no encuentra uno (con algunas excepciones, no entrar en ellos aquí :).

Así que, básicamente, el problema no es la ubicación de las llaves (que en este caso representa un objeto literal, no es un bloque de código, como en la mayoría de los idiomas), pero esta pequeña 'característica' que obliga a su primer ejemplo de return ; =>undefined. Puede verificar el comportamiento de returnin the ES5 spec.

Para otros idiomas que tienen un comportamiento similar, consulte Konrad's answer.

Answer 3

La respuesta a esa pregunta es bastante sencilla. Cualquier lenguaje que tenga "inserción automática de punto y coma" podría tener problemas en esa línea. El problema con este

return 
{ 
    name: 'rajat' 
}; 

..es que el motor js insertará un punto y coma después de la declaración return; (y por lo tanto, volver undefined). Este ejemplo es una buena razón para abrir las llaves siempre en el lado derecho y nunca en el lado izquierdo también. Como ya ha notado correctamente, si hay un corchete en la misma línea, el intérprete lo notará y no podrá insertar un punto y coma.

Answer 4

Lo más seguro. El lenguaje de programación go de Google muestra un comportamiento muy similar (aunque con diferentes efectos). Como se explica allí:

De hecho, lo que ocurre es que el lenguaje formal usa punto y coma, como en C o Java, pero se insertan automáticamente al final de cada línea que parece el final de una instrucción. No necesita escribirlos usted mismo.

..snip ...

Este enfoque hace que para el código de aspecto limpio y sin punto y coma. La única sorpresa es que es importante colocar la llave de apertura de una construcción como una instrucción if en la misma línea que si; si no lo hace, hay situaciones que pueden no compilarse o dar el resultado incorrecto. El lenguaje fuerza el estilo de refuerzo hasta cierto punto.

En secreto, creo que Rob Pike solo quería una excusa para necesitar el estilo de One True Brace.

Answer 5

Fwiw, JSLint informes de varias advertencias con que la sintaxis:

$ jslint -stdin 
function foo(){ 
    return 
    { x: "y" }; 
} 
^D 
(3): lint warning: unexpected end of line; it is ambiguous whether these lines are part of the same statement 
    return 
........^ 

(3): lint warning: missing semicolon 
    { x: "y" }; 
..^ 

(3): lint warning: unreachable code 
    { x: "y" }; 
..^ 

(3): lint warning: meaningless block; curly braces have no impact 
    { x: "y" }; 
..^ 

(3): lint warning: use of label 
    { x: "y" }; 
.....^ 

(3): lint warning: missing semicolon 
    { x: "y" }; 
...........^ 

(3): lint warning: empty statement or extra semicolon 
    { x: "y" }; 
............^ 


0 error(s), 7 warning(s) 

Answer 6

La primera lengua, donde me encontré con este era awk (que también tiene su parte de sintaxis "rarezas"; semi-puntos opcionales, concatenación de cadenas usando solo espacios en blanco y así sucesivamente ...) Creo que los diseñadores de DTrace, que basaron la sintaxis D en awk, tenían suficiente sentido como para NO copiarlos e características, pero no puedo recordar de la parte superior de mi cabeza. Un ejemplo sencillo (contando el número de etiquetas de entidad en una DTD, desde mi Mac):

$ cat printEntities.awk 
# This prints all lines where the string ENTITY occurs 
/ENTITY/ { 
    print $0 
} 
$ awk -f printEntities.awk < /usr/share/texinfo/texinfo.dtd | wc -l 
    119 

Si este pequeño script en su lugar fueron escritos con el aparato ortopédico en una línea propia, esto es lo que sucedería:

$ cat printAll.awk 
# Because of the brace placement, the print statement will be executed 
# for all lines in the input file 
# Lines containing the string ENTITY will be printed twice, 
# because print is the default action, if no other action is specified 
/ENTITY/ 
{ 
    print $0 
} 
$ awk -f printAll.awk < /usr/share/texinfo/texinfo.dtd | wc -l 
    603 
$ /bin/cat < /usr/share/texinfo/texinfo.dtd | wc -l 
    484 
$