Qualsiasi altra lingua diversa da JavaScript ha una differenza tra le posizioni iniziali delle parentesi graffe (stessa riga e riga successiva)?

Oggi, mentre leggevo a caso il libro O'Reilly sui modelli JavaScript, ho trovato una cosa interessante (pagina 27 per riferimento).

In Javascript, in alcuni casi, c'è una differenza se la posizione iniziale della parentesi graffa è diversa.

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

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

Mentre

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

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

JSfiddle Demo

Qualche altra lingua là fuori ha un comportamento simile? Se è così, allora dovrei cambiare di sicuro la mia abitudine .. :)

Sono principalmente preoccupato per PHP, C, C ++, Java e ruby.

Qualsiasi linguaggio che non si basa su punti e virgola (ma invece su newline) per delimitare le istruzioni potenzialmente lo consente. Considera Python :

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

Potresti essere in grado di costruire un caso simile in Visual Basic, ma dalla parte superiore della mia testa non riesco a capire come perché VB è piuttosto restrittivo in cui i valori possono essere inseriti. Ma quanto segue dovrebbe funzionare, a meno che l'analizzatore statico non si lamenti di codice non raggiungibile:

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

Dalle lingue che hai menzionato, Ruby ha la stessa proprietà. PHP, C, C ++ e Java non lo fanno semplicemente perché scartano la nuova riga come spazi bianchi e richiedono punti e virgola per delimitare le istruzioni.

Ecco il codice equivalente dell'esempio Python in Ruby:

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

L'interprete JavaScript aggiunge automaticamente un ;alla fine di ogni riga se non ne trova uno (con alcune eccezioni, non entrarci qui :).

Quindi fondamentalmente il problema non è la posizione delle parentesi graffe (che qui rappresentano un oggetto letterale, non un blocco di codice come nella maggior parte delle lingue), ma questa piccola "caratteristica" che forza il tuo primo esempio a return ;=> undefined. Puoi controllare il comportamento di return nelle specifiche ES5 .

Per altre lingue che hanno un comportamento simile, controlla la risposta di Konrad .

Più probabilmente. Il linguaggio di programmazione go di Google mostra un comportamento molto simile (anche se con effetti diversi). Come spiegato lì:

In effetti, ciò che accade è che il linguaggio formale utilizza i punti e virgola, proprio come in C o Java, ma vengono inseriti automaticamente alla fine di ogni riga che assomiglia alla fine di un'istruzione. Non è necessario digitarli da soli.

..snip ...

Questo approccio consente di ottenere codice dall'aspetto pulito e privo di punti e virgola. L'unica sorpresa è che è importante mettere la parentesi graffa di apertura di un costrutto come un'istruzione if sulla stessa riga dell'if; se non lo fai, ci sono situazioni che potrebbero non essere compilate o potrebbero dare il risultato sbagliato. La lingua impone in una certa misura lo stile delle parentesi graffe.

Segretamente, penso che Rob Pike volesse solo una scusa per richiedere lo stile One True Brace.

La risposta a questa domanda è abbastanza semplice. Qualsiasi lingua con "inserimento automatico del punto e virgola" potrebbe essere in difficoltà su quella riga. Il problema con questo

return
{
     name: 'rajat'
};

..è che il motore js inserirà un punto e virgola dopo l' return;istruzione (e quindi restituirà undefined). Questo esempio è un buon motivo per aprire le parentesi graffe sempre sul lato destro e mai anche sul lato sinistro. Dato che hai già notato correttamente, se c'è una parentesi graffa nella stessa riga, l'interprete lo noterà e non potrà inserire un punto e virgola.

FWIW, JSLint riporta diversi avvisi con quella sintassi:

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

Il primo linguaggio in cui mi sono imbattuto in questo è stato awk (che ha anche la sua parte di sintassi "stranezze"; punti e virgola opzionali, concatenazione di stringhe utilizzando solo spazi bianchi e così via ...) Penso che i designer di DTrace, che hanno basato la sintassi D in modo approssimativo su awk, avevo abbastanza buon senso da NON copiare queste caratteristiche, ma non riesco a ricordare dalla parte superiore della mia testa. Un semplice esempio (contando il numero di tag ENTITY in un DTD, dal mio 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

Se invece questo piccolo script fosse scritto con la parentesi graffa su una riga propria, ecco cosa accadrebbe:

$ 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
$