Perché il recente passaggio alla rimozione / omissione del punto e virgola da Javascript?

Suppongo che la mia ragione sia la più debole: programma in troppi linguaggi diversi allo stesso tempo (Java, Javascript, PHP) - che richiedono ';' quindi piuttosto che allenare le mie dita e gli occhi che il ';' non è necessario per javascript, aggiungo sempre il ';'

L'altro motivo è la documentazione: aggiungendo il ';' Sto dichiarando esplicitamente a me stesso dove mi aspetto che la dichiarazione finisca. Poi di nuovo uso {} sempre.

L'argomento dell'intero byte count che trovo irritante e inutile:

1) per le librerie comuni come jquery: usa la rete CDN di google e probabilmente la libreria sarà già nella cache del browser

2) versione le tue librerie e impostale per essere memorizzate nella cache per sempre.

3) gzip e minimizza se davvero, davvero necessario.

Ma davvero quanti siti hanno come collo di bottiglia più veloce la velocità di download del loro javascript? Se lavori per un sito top 100 come twitter, google, yahoo, ecc. Forse. Il resto di noi dovrebbe semplicemente preoccuparsi della qualità del codice, non delle guerre religiose a punto e virgola.

Rende più semplice il concatenamento dei metodi e fa il commit del pulitore diffs

Quindi diciamo che sto parlando di jQuerying e ho

$('some fancy selector')
  .addClass()
  .attr();

Se voglio aggiungere roba e mantenere il mio commit diff lineare piccolo , devo aggiungerlo sopra attr. Quindi è un pensiero più che "aggiungere alla fine". E chi vuole pensare? =)

$('some fancy selector')
  .addClass()
  // new method calls must go here
  .attr();

Tuttavia, quando faccio cadere il punto e virgola, posso semplicemente aggiungere e chiamarlo un giorno

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate()
+   .click()

Inoltre, se decido di disattivare l'ultimo metodo, non devo riassegnare il punto e virgola e inquinare di nuovo il mio commit.

  $('some fancy selector')
    .addClass()
    .attr()
    .animate()
-   .click()

Contro l'uggo

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate();
-   .animate()
-   .click();

i due punti in JavaScript sono facoltativi

Il mio motivo personale per non utilizzare i due punti è OCD.

Quando utilizzo i semi-punti, ne dimentico il 2% e devo controllarli / aggiungerli costantemente.

Quando non utilizzo i semi-colon non ne metto mai accidentalmente uno in modo da non doverli mai controllare / rimuovere.

Recentemente ho scritto un parser / analizzatore per JavaScript, dove ho dovuto implementare scrupolosamente l'ASI, e ho anche la mia copia di JavaScript: The Good Parts di Crockford sul mio scaffale, che sostiene sempre utilizzando il punto e virgola. L'intenzione era buona, ma non sempre aiuta in pratica.

Ovviamente, le persone che scrivono framework come jQuery, Zepto, ecc. sono maestri di sintassi JavaScript e quindi conoscono la differenza tra:

return
{
    status: true
};

e

return {
    status: true
};

JavaScript, sebbene potente, è anche una lingua per principianti e buona fortuna lo spiega a qualcuno che sta appena imparando che cos'è un ciclo for . Come introdurre la maggior parte delle persone in una nuova abilità, ci sono alcune cose più complesse che non vuoi spiegare subito, così invece scegli di instillare una credenza "cargo setta" in certe cose solo per farle decollare. Quindi, hai due opzioni per insegnare a un principiante come scrivere JavaScript:

1. Di 'loro "segui questa regola e non chiedere perché", dicendo loro di mettere un punto e virgola sempre alla fine di ogni riga. Sfortunatamente, questo non aiuta nell'esempio sopra, o in qualsiasi altro esempio in cui l'ASI si intrometta. E il signor o il programmatore per principianti si sconcerta quando il codice sopra non funziona.
2. Di 'loro "segui queste due regole e non chiedere perché", dicendogli di non disturbarti con il punto e virgola alla fine di ogni riga, e invece sempre a) Segui return con a { , e b) Quando una linea inizia con ( , anteponila con ; .

La scelta dell'opzione 2 è un insieme migliore di regole "cargo setta" da seguire (comporterà pochissimi bug relativi all'ASI), e anche se si ottiene una comprensione approfondita dell'argomento, si hanno meno caratteri non necessari sul schermo.

There’s no such thing as information overload, only bad design.

— Edward Tufte

È un regola generale nella progettazione grafica per eliminare elementi e ornamenti non necessari per ridurre il rumore.

Meno elementi visivi sullo schermo significano meno lavoro per il nostro cervello per analizzare le informazioni utili.

let foo = 1

vs.

let /* variable */ foo = 1; // EOL

Ovviamente un esempio esagerato, ma illustra il principio generale: ulteriori elementi visivi dovrebbero essere aggiunti se e solo se servono a uno scopo. Quindi, i punti e virgola hanno uno scopo?

I motivi storici per utilizzare il punto e virgola in JavaScript erano:

• Mantieni la somiglianza con C / Java
• Evita problemi di compatibilità con browser e strumenti scritti male
• Aiutare umani e macchine a rilevare errori di codice
• L'inserimento automatico del punto e virgola comporta una penalità sulle prestazioni

I problemi di compatibilità sono praticamente un non-problema oggi. I moderni linters possono rilevare qualsiasi errore di codice altrettanto bene senza punto e virgola. La somiglianza con C / Java / PHP può essere ancora una considerazione (vedi la risposta accettata di Pat), ma solo perché altri linguaggi contengono elementi di sintassi superflui, non significa che dovremmo tenerli in JavaScript, soprattutto perché molti altri linguaggi (Coffeescript, Python, Ruby, Scala, Lua) non li richiedono.

Ho fatto un rapido test per vedere se c'era una penalizzazione delle prestazioni nel V8. Questo è Io.js che analizza un file JavaScript di 41 MB (Lodash ripetuto 100 volte) con punto e virgola e quindi con punto e virgola rimosso:

$ time node lodashx100.js
node lodashx100.js  2.34s user 1.30s system 99% cpu 3.664 total
$ time node lodashx100s.js
node lodashx100s.js  2.34s user 1.15s system 99% cpu 3.521 total

Ognuno deve decidere il proprio stile di codifica preferito per i propri progetti, ma non vedo più alcun vantaggio tangibile nell'uso del punto e virgola, quindi per ridurre il rumore visivo, mi sono fermato.

La scelta di una convenzione di programmazione equivale in modo efficace alla scelta del sottoinsieme della lingua di destinazione. Lo facciamo tutti per i soliti motivi: leggibilità del codice, manutenibilità, stabilità, portabilità, ecc., Pur sacrificando la flessibilità. Queste ragioni sono vere ragioni di business.

Motivi come "salvare le sequenze di tasti" e "i programmatori dovrebbero imparare le regole JavaScript" sono motivi commerciali marginali, quindi hanno un peso pratico minimo.

Nel mio caso, avevo bisogno di venire in velocità in JavaScript molto velocemente, quindi sfruttare un sottoinsieme limitato della lingua era a mio vantaggio. Così ho scelto il sottoinsieme JSLint di JavaScript, attivato le app Rockstar JSLinter in Eclipse per le impostazioni più restrittive che potevo sopportare e non ho guardato indietro.

Sono grato di essere in grado di evitare i dettagli della differenza tra "==" e "===", o i dettagli dell'inserimento punto e virgola, perché ho già un elenco di attività alto un miglio e quei dettagli non aiuterà a fare quei lavori fatti un secondo prima.

Ovviamente la cosa più importante di una convention è la coerenza, e pensarla come un sottoinsieme della lingua aiuta a rafforzare questo imperativo. E anche se questo non può aiutare a rispondere alla domanda dell'OP, penso che potrebbe essere d'aiuto con la definizione pratica di esso.

Una domanda piuttosto vecchia, tuttavia sono sorpreso che nessuno abbia menzionato:

Minification: se ti capita di minimizzare uno snippet di JavaScript che non termina esplicitamente le affermazioni con un carattere di punto e virgola, potresti avere difficoltà a cercare di capire cosa è sbagliato con uno snippet che stava funzionando prima del minification e ora non funziona.

Ambiguità: I semi-colon sono opzionali, true, tuttavia eliminandoli dal codice sorgente, potresti lasciare alcuni scenari ambigui al parser per decidere autonomamente. Se stai scrivendo 100 righe di codice per un negozio online, sì, forse non importa, ma attività più serie richiederebbero una chiarezza del 100%.

Molto tempo fa ho letto un'analogia molto carina su qualcos'altro, ma è anche vero in questo caso: (Nel nostro caso) Eliminare il punto e virgola è come attraversare una luce rossa. Alla fine potresti essere a posto o potresti essere investito da un camion.

Perché sta diventando più popolare in questi giorni?

Personalmente ritengo che l'esecuzione di JavaScript sul lato server abbia avuto molti effetti sulla comunità JavaScript stessa. Nel nostro caso, ovviamente, nessuno minimizzerà il JavaScript sul lato server (poiché il codice sorgente non dovrebbe essere spedito al browser del client), quindi non avere un punto e virgola sembra molto più sicuro, il che è vero; tuttavia, gli altri sviluppatori che apprendono da questi libri, articoli e video sfortunatamente ignorano il fatto che JavaScript sul lato server non è esattamente lo stesso di JavaScript sul lato client.

Ci sono buoni motivi per tenerli dentro.

Non sono realmente opzionali, JS può aggiungerli di nuovo con l'inserimento automatico del punto e virgola quando mancano, ma non è la stessa cosa.

JavaScript di Douglas Crockford: The Good Parts dice in due diverse occasioni che è una cattiva idea. L'inserimento automatico del punto e virgola può nascondere i bug nel tuo programma e creare ambiguità.

JSLint non approva.

JavaScript non ha richiesto il punto e virgola per terminare le dichiarazioni in oltre un decennio. Questo perché i caratteri di nuova riga sono considerati terminatori di istruzioni (credo che ciò sia menzionato anche nelle prime specifiche di ECMAScript). Ha davvero molto senso, soprattutto perché non c'è davvero una buona ragione [che io sappia] perché JavaScript avrebbe bisogno di un uso frequente di punti e virgola, ma non di altri linguaggi dichiarativi interpretati come Ruby o Python.

Richiedere il punto e virgola può semplificare la scrittura di un parser per una lingua, ma se l'interprete ogni supporta l'omissione di punti e virgola, allora qual è esattamente il punto?

Ciò che si capisce è quanto è esperto un programmatore: se sai che puoi omettere un punto e virgola, sentiti libero di capire che potrebbe esserci o meno una conseguenza. Gli esseri umani sono macchine decisionali e quasi tutte le decisioni richiedono un compromesso o un compromesso. Il compromesso con il lancio di semi-colon attorno al tuo codice (anche in luoghi in cui non sono necessari) è che il tuo codice diventa meno leggibile (a seconda di chi chiedi) e JSLint non si lamenterà (a chi importa ). D'altra parte, il trade-off di omettere i semi-colon è il fatto che il 90% dei programmatori JavaScript ti castigherà per questo, ma potresti finire per divertirti a scrivere JavaScript per questo.

Cosa ti suona meglio; prendere decisioni informate o prendere decisioni cieche / mentalità di un branco?

Ho due teorie:

A)

La cosa su questa scelta è che nel passato, quando erano applicabili JSLint ecc., si stava scegliendo di impiegare una notevole quantità di tempo a trovare errori di sintassi oscuri o una quantità ragionevole di tempo per applicare una politica di standard sul codice.

Tuttavia, mentre ci muoviamo di più verso il Test unitario - codice guidato e integrazione continua, è necessario il tempo (e l'interazione umana) richiesti per catturare un errore di sintassi è diminuito in modo massiccio. I feedback dei test indicheranno rapidamente se il tuo codice funziona come previsto, molto prima che si avvicini a un utente finale, quindi perché perdere tempo aggiungendo verbosità facoltativa?

B)

I programmatori pigri faranno di tutto per rendere la propria vita più facile a breve termine. Meno digitando - > meno sforzo - > Più facile. (inoltre, non avendo il punto e virgola eviterai di sforzare l'anulare della mano destra, evitando qualche RSIness).

(NB Non sono d'accordo con l'idea di omettere qualcosa che disambiguates una dichiarazione).

Non li lascio fuori, ma cambio le regole quando inserirli.

Le regole utilizzate dalla maggior parte delle persone sono

• Prima di ogni riga che termina
• Tranne che la riga termina con un } proveniente da un'istruzione di funzione
• Ma solo un'istruzione di funzione, non un'assegnazione a una funzione letterale

La mia regola è: all'inizio di ogni singola riga che inizia con una parentesi graffa / parentesi aperta.

Il mio è più semplice, quindi più facile da seguire e meno incline ai bug. Inoltre, il basso numero di punti e virgola facilita la ricerca di bug eliminati.

Un altro argomento è che il famigerato errore return\nvalue deriva dal non sapere sull'ASI. La mia regola ti obbliga a conoscere l'ASI, quindi le persone che usano la mia regola hanno meno probabilità di cadere nella trappola di quell'errore.

Numero di byte. Vedete, le persone malintenzionate di solito cercano di adattarsi così tanto a una singola riga di codice. Tecnicamente parlando, questo non sarebbe possibile senza punti e virgola. Suppongo che sia più una misura di sicurezza che un semplice requisito programmatico. In qualche modo, questo ridurrebbe significativamente l'XSS quando diventerà un requisito piuttosto che un suggerimento.