usa - ¿cuál de estas instrucciones está correctamente escrita en javascript?
¿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)? (6)
Hoy, mientras estaba leyendo aleatoriamente los patrones de JavaScript del libro 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
¿Hay algún otro idioma que tenga ese tipo de comportamiento? Si es así, entonces tendría que cambiar mi hábito de seguro ... :)
Me preocupan principalmente PHP, C, C ++, Java y Ruby.
El intérprete de JavaScript agrega automáticamente un ; al final de cada línea si no encuentra una (con algunas excepciones, no entrar en ellas aquí :).
Así que, básicamente, el problema no es la ubicación de las llaves (que aquí representan un objeto literal, no un bloque de códigos como en la mayoría de los lenguajes), sino esta pequeña "característica" que obliga a que return ; el primer ejemplo return ; => undefined . Puede verificar el comportamiento de return en la especificación ES5 .
Para otros idiomas que tienen un comportamiento similar, consulte la respuesta de Konrad .
El primer idioma en el que me encontré con esto fue awk (que también tiene su parte de sintaxis "rarezas", puntos y comas 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 de manera vaga en awk, tuve el suficiente sentido común como para NO copiar estas características, pero no puedo recordar lo que tengo en la cabeza. Un ejemplo simple (contando el número de etiquetas ENTITY 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 guión en su lugar fuera escrito con la llave 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
$
FWIW, JSLint informa varias advertencias con esa 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)
La respuesta a esa pregunta es bastante fácil. Cualquier lenguaje que tenga "inserción automática de punto y coma" podría tener problemas en esa línea. El problema con esto
return
{
name: ''rajat''
};
... es que el motor js insertará un punto y coma después de la return; declaración (y por lo tanto, retorno undefined ). Este ejemplo es una buena razón para abrir los corchetes 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.
Seguramente. 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 sucede es que el lenguaje formal usa punto y coma, tanto como en C o Java, pero se insertan automáticamente al final de cada línea que se ve como el final de un enunciado. No necesita escribirlos usted mismo.
..recorte...
Este enfoque proporciona un código 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 requerir el estilo de One True Brace.
Cualquier lenguaje que no se base en punto y coma (pero en cambio en líneas nuevas) para delimitar declaraciones potencialmente lo permite. Considera Python :
>>> def foo():
... return
... { 1: 2 }
...
>>> def bar():
... return { 1: 2 }
...
>>> foo()
>>> bar()
{1: 2}
Es posible que pueda construir un caso similar en Visual Basic pero fuera de mi cabeza No puedo entender cómo porque VB es bastante restrictivo en cuanto a dónde se pueden colocar los valores. Pero lo siguiente debería funcionar, a menos que el analizador estático se queje de un 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 los idiomas que mencionaste, Ruby 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 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