Perché il recente passaggio alla rimozione / omissione di punti e virgola da Javascript?

Recentemente sembra di moda omettere i punti e virgola da Javascript. Qualche anno fa è stato pubblicato un post sul blog che sottolineava che in Javascript i punti e virgola sono facoltativi e l'essenza del post sembrava essere che non dovresti preoccuparti di loro perché non sono necessari. Il post, ampiamente citato, non fornisce ragioni convincenti per non usarli, solo che lasciarli fuori ha pochi effetti collaterali.

Perfino GitHub è saltato sul carrozzone senza punto e virgola, richiedendo la loro omissione in qualsiasi codice sviluppato internamente, e un recente commit nel progetto zepto.js da parte del suo manutentore ha rimosso tutti i punti e virgola dalla base di codice. Le sue principali giustificazioni erano:

• è una questione di preferenza per la sua squadra;
• meno battitura a macchina

Ci sono altri buoni motivi per lasciarli fuori?

Francamente non vedo alcun motivo per ometterli, e certamente nessun motivo per tornare indietro sul codice per cancellarli. Va anche contro ( anni di ) pratica raccomandata , per la quale non compro realmente l'argomento "cult cult". Quindi, perché tutto il recente punto e virgola odio? C'è una carenza che incombe? O è solo l'ultima moda Javascript?

Suppongo che la mia ragione sia la più pessima: programma in troppe lingue diverse contemporaneamente (Java, Javascript, PHP) - che richiedono ';' così piuttosto che allenare le dita e gli occhi che il ';' non è necessario per javascript, aggiungo sempre sempre ';'

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

L'intero argomento del conteggio dei byte lo trovo irritante e inutile:

1) per librerie comuni come jquery: usa google CDN 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 minimizzare se davvero, davvero necessario.

Ma davvero quanti siti hanno come maggiore velocità il collo di bottiglia rispetto alla velocità di download del loro javascript? Se lavori per uno dei primi 100 siti come Twitter, Google, Yahoo, ecc. Forse. Il resto di noi dovrebbe preoccuparsi solo della qualità del codice e non delle guerre di punto e virgola.

Rende il concatenamento dei metodi più semplice e rende le differenze più pulite

Quindi diciamo che sto jQuerying e ho

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

Se voglio aggiungere elementi e mantenere piccolo il mio commit basato sulla linea , devo aggiungerlo sopra attr. Quindi è un pensiero più lungo di un semplice "aggiungi alla fine". E chi vuole pensare? =)

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

Ma quando lascio cadere i punti e virgola, posso semplicemente aggiungere e chiamarlo un giorno

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

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

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

Contro l'Uggo

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

i punti e virgola in JavaScript sono opzionali

La mia ragione personale per non usare i punti e virgola è il DOC.

Quando uso i punti e virgola, ne dimentico il 2% e devo controllarli / aggiungerli continuamente.

Quando non uso i punti e virgola, non ne inserisco mai uno accidentalmente, quindi non devo mai controllarli / rimuoverli.

Di recente ho scritto un parser / analizzatore per JavaScript, dove ho dovuto implementare scrupolosamente l'ASI, e ho anche la mia copia del JavaScript di Crockford : The Good Parts sulla mia libreria, che sostiene sempre di utilizzare i punti e virgola. L'intenzione era buona, ma non sempre aiuta nella 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 a spiegarlo a qualcuno che sta imparando cos'è un forloop. Come introdurre la maggior parte delle persone a una nuova abilità, ci sono alcune cose più complesse che non vuoi spiegare subito, quindi invece scegli di infondere una credenza da "cult del carico" in certe cose solo per farle decollare. Quindi, hai due scelte quando insegni a un principiante come scrivere JavaScript:

1. Dì loro "segui questa regola e non chiedere perché", dicendo loro di mettere sempre un punto e virgola alla fine di ogni riga. Sfortunatamente, questo non aiuta nell'esempio sopra, o in qualsiasi altro esempio in cui l'ASI si mette di mezzo. E il programmatore per principianti Mr. o Ms. viene confuso quando il codice sopra non riesce.
2. Dì loro "segui queste due regole e non chiedere perché", dicendo loro di non preoccuparsi dei punti e virgola alla fine di ogni riga e invece di sempre a) Segui returncon a {e b) Quando una riga inizia con a (, anteponi con a ;.

La scelta dell'opzione 2 è una serie migliore di regole da seguire per il "culto delle merci" (comporterà pochissimi bug relativi all'ASI) e anche se si ottiene una profonda comprensione dell'argomento, sullo schermo sono presenti meno caratteri non necessari.

Non esiste un sovraccarico di informazioni, solo un cattivo design.

- Edward Tufte

È una regola generale nella progettazione grafica escludere 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 effettive.

let foo = 1

vs.

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

Un esempio esagerato ovviamente, 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 i punti e virgola in JavaScript erano:

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

I problemi di compatibilità sono praticamente un non-problema oggi. I linter moderni possono rilevare anche eventuali errori di codice senza punti e virgola. La somiglianza con C / Java / PHP può ancora essere considerata (vedi la risposta accettata da Pat), ma solo perché altre lingue contengono elementi di sintassi superflui non significa che dovremmo tenerli in JavaScript, soprattutto perché molte altre lingue (Coffeescript, Python, Ruby, Scala, Lua) non li richiedono.

Ho fatto un rapido test per vedere se ci fosse una penalità di prestazione nel V8. Questo è Io.js che analizza un file JavaScript da 41 MB (Lodash ripetuto 100 volte) con punti e virgola e quindi con punti e virgola rimossi:

$ 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 beneficio tangibile nell'uso dei punti e virgola, quindi per ridurre il rumore visivo, mi sono fermato.

La scelta di una convenzione di programmazione equivale effettivamente alla scelta di un sottoinsieme della lingua di destinazione. Lo facciamo tutti per i soliti motivi: leggibilità del codice, manutenibilità, stabilità, portabilità, ecc., Sacrificando potenzialmente la flessibilità. Queste ragioni sono vere ragioni commerciali.

Ragioni come "il salvataggio delle sequenze di tasti" e "i programmatori dovrebbero apprendere le regole JavaScript" sono motivi commerciali marginali, quindi hanno poco peso pratico.

Nel mio caso avevo bisogno di accelerare JavaScript molto velocemente, quindi sfruttare un sottoinsieme limitato della lingua era a mio vantaggio. Quindi ho scelto il sottoinsieme JSLint di JavaScript, ho attivato le app Rockstar JSLinter in Eclipse alle impostazioni più restrittive che potessi 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 del punto e virgola, perché ho già un elenco di attività alto un miglio e quei dettagli non lo faranno aiutare a fare quei lavori un secondo prima.

Naturalmente la cosa più importante di una convenzione è la coerenza, e pensarla come un sottoinsieme linguistico aiuta a rafforzare questo imperativo. E sebbene ciò possa non aiutare a rispondere alla domanda del PO, penso che potrebbe essere d'aiuto con la sua definizione pratica.

Piuttosto una vecchia domanda, tuttavia sono sorpreso che nessuno abbia menzionato:

Minificazione: se ti capita di minimizzare uno snippet JavaScript che non termina esplicitamente le dichiarazioni con un carattere punto e virgola, potresti finire per avere difficoltà a capire cosa c'è che non va in uno snippet che stava funzionando prima della minificazione e ora non funziona.

Ambiguità: i punti e virgola sono opzionali, veri, tuttavia eliminandoli dal codice sorgente, è possibile lasciare al parser alcuni scenari ambigui per decidere autonomamente. Se stai scrivendo 100 righe di codice per un negozio online, sì, forse non importa, ma compiti più seri richiederebbero una chiarezza del 100%.

Molto tempo fa ho letto una bella analogia su qualcos'altro, ma è anche vero in questo caso: (Nel nostro caso) Eliminare i punti e virgola è come attraversare a una luce rossa. Potresti andare bene alla fine o potresti essere colpito da un camion.

Perché sta diventando più popolare in questi giorni?

Personalmente credo che avere JavaScript eseguito sul lato server abbia avuto molti effetti sulla stessa comunità JavaScript. Nel nostro caso, ovviamente nessuno minimizzerà il JavaScript sul lato server (poiché il codice sorgente non dovrebbe essere spedito al browser web del client), quindi non avere punti e virgola sembra molto più sicuro, il che è vero; tuttavia gli altri sviluppatori che imparano da questi libri, articoli e video, purtroppo respingono il fatto che JavaScript sul lato server non è esattamente uguale a JavaScript sul lato client.

Ci sono buoni motivi per tenerli dentro.

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

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

JSLint non approva.

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

La richiesta di punti e virgola può rendere più semplice la scrittura di un parser per una lingua, ma se ogni interprete là fuori supporta l'omissione dei punti e virgola, qual è esattamente il punto?

Ciò che si riduce è quanto un programmatore sia ben informato: se sai che puoi omettere un punto e virgola, sentiti libero di farlo comprendendo 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 semplice lancio di punti e virgola in tutto il codice (anche nei luoghi in cui non sono necessari) è che il codice diventa meno leggibile (a seconda di chi chiedi) e JSLint non si lamenterà (chi se ne frega ). D'altra parte, il compromesso per omettere i punti e virgola è il fatto che il 90% dei programmatori JavaScript ti castigherà per questo, ma potresti finire per divertirti a scrivere JavaScript di più a causa di ciò.

Cosa ti suona meglio; prendere decisioni informate o prendere decisioni cieche / mentalità da gregge?

Ho due teorie:

UN)

La cosa su questa scelta è che nel passato, quando erano applicabili JSLint ecc., Stavi scegliendo di dedicare molto tempo a rilevare oscuri errori di sintassi o un ragionevole periodo di tempo per applicare una politica standard sul codice.

Tuttavia, man mano che ci spostiamo maggiormente verso il codice guidato da Unit Test e l'integrazione continua, il tempo (e l'interazione umana) necessario per rilevare un errore di sintassi è diminuito in modo massiccio. Il feedback dei test indicherà rapidamente se il codice funziona come previsto, ben prima che si avvicini a un utente finale, quindi perché perdere tempo ad aggiungere verbosità opzionale?

B)

I programmatori pigri faranno di tutto per semplificare la propria vita a breve termine. Meno battitura a macchina -> meno sforzo -> più facile. (inoltre, non dover utilizzare il punto e virgola eviterà di sforzare l'anulare destro, evitando un po 'di RSI).

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

Non li tralascio, ma cambio le regole quando inserirli.

Le regole che usano la maggior parte delle persone

• Prima della fine di ogni riga
• 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 soggetto a bug. Inoltre, il basso numero di punti e virgola rende facile la ricerca di bug creati lasciandolo fuori.

Un altro argomento è che il famigerato return\nvaluebug deriva dal non conoscere l'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 quel bug.

Conteggio byte. Vedete, le persone maligne di solito cercano di inserirsi così tanto in una singola riga di codice. Tecnicamente parlando, ciò non sarebbe possibile senza punti e virgola. La mia supposizione è che si tratti più di una misura di sicurezza che di un semplice requisito programmatico. In qualche modo, ciò ridurrebbe significativamente l'XSS quando diventa un requisito piuttosto che un suggerimento.