2010-06-09 18 views
11

Ho appena visto un video della presentazione di Douglas Crockford sul suo libro del 2009 JavaScript: The Good Parts.Lo stile di blocco è davvero così importante?

Nel video, spiega che il seguente blocco è pericoloso perché produce errori silenti:

return 
{ 
    ok: false 
}; 

e che dovrebbe in realtà essere scritto come questo (sottolineando che anche se apparentemente identica la differenza comportamentale è fondamentale) :

return { 
    ok: false 
}; 

È possibile vedere i suoi commenti intorno al 32 ° minuto il video qui: http://www.youtube.com/watch?v=hQVTIJBZook&feature=player_embedded#!&start=1920

Non l'ho mai sentito prima e mi chiedevo se questa regola si applica ancora o se questo requisito nella sintassi è stato superato dagli sviluppi JavaScript da quando è stata fatta questa dichiarazione.

Ho trovato questo molto interessante come NON ho scritto il mio codice in questo modo, e volevo controllare che questa informazione non fosse scaduta.

+1

Spiega quali sono gli errori e qual è la differenza comportamentale? – ChrisF

+0

Sì, se dai un'occhiata al video da 32 minuti vedrai la sua spiegazione completa. –

risposta

15

L'errore silenzioso è che viene restituito undefined!

virgola sono opzionali in JavaScript, e quindi

return 
{ 
    ok: false 
}; 

viene analizzato come se fosse

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

JSLint riconosceranno tali modelli e mettere in guardia su di loro:

lint avviso: inaspettato fine linea; è ambigua se queste linee sono parte della stessa istruzione

avvisi lanugine: mancante virgola

avvisi lanugine: codice irraggiungibile

avvisi lanugine: blocco insignificante; parentesi graffe non hanno alcun impatto

Questo è stato discusso su SO nella domanda "Strangest language feature".

+1

'return;' restituisce una funzione 'undefined', non' null' –

+0

'undefined' viene restituito, piuttosto che' null', no? – Matt

+0

@Delan @Matt, ovviamente corretto. Saluti. –

2

Javascript inserirà un punto e virgola dopo il ritorno, perché "sembra mancare".

Quello che segue è un blocco di {ok: falso} che non ha alcun effetto.

Quindi è un bug nella specifica JavaScript ..

La mia raccomandazione è gestito JSLint ogni volta che potete, e configurarlo per consentire per il vostro stile quando è differente da Crockford di.

3

La regola si applica ancora.

Perché la lingua inserisce automaticamente "dispersi" e virgola, il primo pezzo viene interpretato come:

return; 

{ 
    ok: false 
}; 

cioè, undefined viene restituito. Se il codice fosse in qualche modo autorizzato a superare l'istruzione return, un oggetto sarebbe quindi creato, ma non sarebbe assegnato a qualcosa di utile (una variabile).

0

Questo è un problema molto reale. Restituire involontariamente un null può sicuramente fare brutte cose nel tuo codice!

+0

Restituire un 'indefinito', non un' nullo' ... –

0

La regola si applica anche oggi ed è una delle "parti danneggiate". Il primo snippet di codice renderà la funzione restituita undefined.

vedere la mia altra risposta su questo argomento: Semicolon in C++?

0

Javascript è "amichevole" abbastanza per assumere un punto e virgola a interruzioni di riga in alcuni casi. Io in realtà ha scritto un blog su che qualche tempo fa:

Javascript – almost not line based

La parte che riguarda l'istruzione return va:

Tuttavia, ci sono alcune cose che non si può fare. Se per esempio si inserisce un'interruzione di riga tra la parola chiave di ritorno e il suo argomento, all'improvviso ha un significato diverso da . Se si formatta il codice come questo:

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

Poi viene interpretato in questo modo:

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

L'istruzione return prende il modulo senza parametri, e l'argomento diventa una dichiarazione a parte.

0

Chiedendosi perché le persone decidono di rendere le cose facoltative, non ti costa quasi nulla aggiungere un punto e virgola. Ma il debug di questa situazione può richiedere molto tempo.

Più in generale, perché il progettista di linguaggi ha continuato a pensare che il codice dovesse auto-guarire da un errore dell'utente. Se le persone sbagliano dovrebbe essere avvertito. Altrimenti ti metteresti nei guai più tardi.

E sappiamo che più tardi capirai di sbagliare più sarà costoso.

Problemi correlati