JSLint, il resto e ci aspettavamo esattamente uno spazio tra '}' e l'errore 'altro'

Question

Perché JSLint rapporto in codice:

function cos(a) { 
    var b = 0; 
    if (a) { 
     b = 1; 
    } 
    else { 
     b = 2; 
    } 

    return b; 
} 

errore:

Problem at line 6 character 5: Expected exactly one space between '}' and 'else'. 

Questo errore può essere disattivato disabilitando Tollerare lo spazio bianco disordinato opzione di JSLint.

O in altre parole - il motivo per cui sintassi: } else { è meglio allora

... 
} 
else { 
... 

Google also uses sintassi con } else { modulo.

Ma non capisco perché. Google ha citato "inserimento di punto e virgola implicito", ma nel contesto dell'apertura di {, non chiudendone uno.

Può Javascript inserire e virgola dopo la chiusura } di if blocco, anche se la prossima pedina è else istruzioni?

Scusa che la mia domanda è un po 'caotica - ho provato a pensare forte.

Answer 1

JSLint è basato sulle preferenze di Crockford (che condivido in questo caso).

È una questione di opinione che è "migliore".

(Anche se chiaramente la sua opinione è di destra;)

Answer 2

JSLint è solo essere pignoli qui. Il tizio che lo ha scritto ha anche fornito molti suggerimenti stilistici per mantenere il proprio codice più coerente.

Come per l'inserimento del punto e virgola, non è necessario preoccuparsi qui. Inserendo un punto e virgola prima che la clausola else portasse a un errore di sintassi e l'inserimento automatico del punto e virgola si verifica solo in situazioni in cui il codice risultante sarebbe ancora sintatticamente valido.

Se volete saperne di più su di inserimento e virgola, vi consiglio this nice reference

In sostanza se si inserisce un punto e virgola in tutto il mondo è necessario solo essere attenti a mettere l'argomento di "ritornare" o "tiro" (o l'etichetta per " pausa "e" continua ") sulla stessa riga.

E quando si dimentica accidentalmente un punto e virgola, gli unici casi comuni che probabilmente ti mordono sono se si avvia la riga successiva con un letterale di matrice (che potrebbe essere analizzato come operatore di pedici) o un'espressione di parentesi (potrebbe essere analizzato come una chiamata di funzione)

Conclusion

Should you omit optional semicolons or not? The answer is a matter of personal preference, but should be made on the basis of informed choice rather than nebulous fears of unknown syntactical traps or nonexistent browser bugs. If you remember the rules given here, you are equipped to make your own choices, and to read any JavaScript easily.

If you choose to omit semicolons where possible, my advice is to insert them immediately before the opening parenthesis or square bracket in any statement that begins with one of those tokens, or any which begins with one of the arithmetic operator tokens "/", "+", or "-" if you should happen to write such a statement.

Whether you omit semicolons or not, you must remember the restricted productions (return, break, continue, throw, and the postfix increment and decrement operators), and you should feel free to use linebreaks everywhere else to improve the readability of your code.

---

a proposito, io personalmente penso che la versione } else { è più bella. Smetti di insistere nei tuoi modi cattivi e unisciti a noi dal lato leggero della forza: P

Answer 3

JSLint è molto pignolo qui, applica semplicemente uno stile che potresti non condividere.

Prova JSHint invece:

The project originally started as an effort to make a more configurable version of JSLint—the one that doesn't enforce one particular coding style on its users [...]

Answer 4

Non è una questione di stile. È come funziona ECMAScript.

Nel bene e nel male, si inserirà automaticamente un punto e virgola alla fine di dichiarazioni in cui ci si sente necessario.

JavaScript potrebbe interpretare questo:

function someFunc { 
    return 
    { 
     something: 'My Value' 
    }; 
} 

Come questo:

function someFunc { 
    return; 
    { 
     something: 'My Value' 
    }; 
} 

che è certamente ciò che non lo fanno vogliono.

Se si posiziona sempre la staffa sulla stessa riga dell'istruzione if e if else, non si verificherà un problema di questo tipo.

Come con qualsiasi linguaggio di programmazione, lo stile di codifica scelto dovrebbe essere quello che riduce al minimo il rischio potenziale di più.

Mozilla Developer Network promuove anche la stessa linea bracketing: https://developer.mozilla.org/en-US/docs/User:GavinSharp_JS_Style_Guidelines#Brackets

Answer 5

Ho appena finito di leggere un libro intitolato Mastering JavaScript ad alte prestazioni. Parlo sotto correzione qui, ma da quello che posso raccogliere è che lo "spazio bianco" in realtà conta.

Ha a che fare con il modo in cui l'interprete recupera la funzione successiva. Mantenendo lo spazio bianco al minimo (ad esempio) utilizzando un minificatore quando il codice è pronto per la distribuzione, si accelera effettivamente il processo.

Se l'interprete deve cercare attraverso lo spazio bianco per trovare l'istruzione successiva questo richiede tempo. Forse si vuole testare questo con un pezzo di codice che viene eseguito un ciclo dici 10.000 volte con lo spazio bianco in esso e poi lo stesso codice minimizzato.

La dichiarazione di mettere prima dell'inizio del ciclo sarebbe console.time e infine console.timeEnd alla fine del ciclo. Questo ti dirà poi quanti millisecondi hanno impiegato il ciclo per calcolare.

Answer 6

Il JSLint errore/avvertimento suggerisce di modificare il codice per

// naming convention winner? it's subjective 
} else if{ 
    b = 2; 
} 

da:

} 
else if{ 
b = 2; 
} 

Previene insert semicolons; considerato più standard & convenzionale. molte persone potrebbero concordare una scheda tra }tabelse if{

non è il metodo più popolare. Interessante come la parentesi di apertura { sia posizionata (spazio o meno), ovviamente entrambe sono soggette a