Qui nulla è scolpito nella pietra. Queste sono preferenze di stile, non dogmi religiosi.

// backtick quotes ` allow to split the string into multiple lineslet str = ` ECMA International's TC39 is a group of JavaScript developers, implementers, academics, and more, collaborating with the community to maintain and evolve the definition of JavaScript.`;

E, perif istruzioni:

if ( id === 123 && moonPhase === 'Waning Gibbous' && zodiacSign === 'Libra') { letTheSorceryBegin();}

La lunghezza massima della linea deve essere concordata a livello di squadra. Di solito sono 80 o 120 caratteri.

Rientri

Esistono due tipi di rientri:

• Rientri orizzontali: 2 o 4 spazi.

  Un rientro orizzontale viene effettuato utilizzando 2 o 4 spazi o il simbolo tab orizzontale (tasto Tab). Quale scegliere è una vecchia guerra santa. Gli spazi sono più comuni al giorno d’oggi.

  Un vantaggio degli spazi rispetto alle schede è che gli spazi consentono configurazioni più flessibili dei rientri rispetto al simbolo della scheda.

  Ad esempio, possiamo allineare i parametri con la parentesi di apertura, in questo modo:

  show(parameters, aligned, // 5 spaces padding at the left one, after, another ) { // ...}

• Rientri verticali: linee vuote per suddividere il codice in blocchi logici.

  Anche una singola funzione può spesso essere divisa in blocchi logici. Nell’esempio seguente, l’inizializzazione delle variabili, il ciclo principale e il ritorno del risultato sono divisi verticalmente:

  function pow(x, n) { let result = 1; // <-- for (let i = 0; i < n; i++) { result *= x; } // <-- return result;}

  Inserire una nuova riga in più dove aiuta a rendere il codice più leggibile. Non ci dovrebbero essere più di nove righe di codice senza un rientro verticale.

  Punto e virgola

  Un punto e virgola dovrebbe essere presente dopo ogni istruzione, anche se potrebbe essere saltato.

  Ci sono lingue in cui un punto e virgola è veramente facoltativo e viene usato raramente. In JavaScript, tuttavia, ci sono casi in cui un’interruzione di riga non viene interpretata come punto e virgola, lasciando il codice vulnerabile agli errori. Vedere di più su questo nel capitolo Struttura del codice.

  Se sei un programmatore JavaScript esperto, puoi scegliere uno stile di codice senza punto e virgola come StandardJS. Altrimenti, è meglio usare il punto e virgola per evitare possibili insidie. La maggior parte degli sviluppatori mette il punto e virgola.

  Livelli di nidificazione

  Cercare di evitare il codice di nidificazione troppi livelli in profondità.

  Ad esempio, nel ciclo, a volte è una buona idea usare la direttivacontinue per evitare il nesting aggiuntivo.

  Ad esempio, invece di aggiungere unif condizionale nidificato come questo:

  for (let i = 0; i < 10; i++) { if (cond) { ... // <- one more nesting level }}

  Possiamo scrivere:

  for (let i = 0; i < 10; i++) { if (!cond) continue; ... // <- no extra nesting level}

  Una cosa simile può essere fatta conif/else e return.

  Ad esempio, due costrutti di seguito sono identici.

  Opzione 1:

  function pow(x, n) { if (n < 0) { alert("Negative 'n' not supported"); } else { let result = 1; for (let i = 0; i < n; i++) { result *= x; } return result; }}

  Opzione 2:

  function pow(x, n) { if (n < 0) { alert("Negative 'n' not supported"); return; } let result = 1; for (let i = 0; i < n; i++) { result *= x; } return result;}

  Il secondo è più leggibile perché il “caso speciale” di n < 0 è gestito presto. Una volta che il controllo è fatto possiamo passare al flusso di codice “principale” senza la necessità di annidamento aggiuntivo.

  Posizionamento delle funzioni

  Se si scrivono diverse funzioni “helper” e il codice che le utilizza, ci sono tre modi per organizzare le funzioni.

  La maggior parte del tempo, la seconda variante è preferita.

  Questo perché durante la lettura del codice, vogliamo prima sapere cosa fa. Se il codice va per primo, diventa chiaro fin dall’inizio. Quindi, forse non avremo bisogno di leggere affatto le funzioni, specialmente se i loro nomi sono descrittivi di ciò che effettivamente fanno.

  Guide di stile

  Una guida di stile contiene regole generali su “come scrivere” il codice, ad esempio quali citazioni usare, quanti spazi indentare, la lunghezza massima della linea, ecc. Un sacco di cose minori.

  Quando tutti i membri di un team usano la stessa guida di stile, il codice appare uniforme, indipendentemente dal membro del team che lo ha scritto.

  Naturalmente, un team può sempre scrivere la propria guida di stile, ma di solito non ce n’è bisogno. Ci sono molte guide esistenti tra cui scegliere.

  Alcune scelte popolari:

  • Google JavaScript Style Guide
  • Airbnb JavaScript Style Guide
  • Idiomatica.JS
  • StandardJS
  • (più molti altri)

  Se sei uno sviluppatore alle prime armi, inizia con il cheat sheet all’inizio di questo capitolo. Quindi puoi sfogliare altre guide di stile per raccogliere più idee e decidere quale ti piace di più.

  Linters automatizzati

  Linters sono strumenti che possono controllare automaticamente lo stile del codice e dare suggerimenti per migliorare.

  La cosa grandiosa di loro è che il controllo dello stile può anche trovare alcuni bug, come errori di battitura nei nomi di variabili o funzioni. A causa di questa funzione, si consiglia di utilizzare un linter anche se non si desidera attenersi a un particolare “stile di codice”.

  Ecco alcuni strumenti di linting ben noti:

  • JSLint-uno dei primi linter.
  • JSHint – più impostazioni di JSLint.
  • ESLint-probabilmente il più nuovo.

  Tutti possono fare il lavoro. L’autore usa ESLint.

  La maggior parte dei linter sono integrati con molti editor popolari: basta abilitare il plugin nell’editor e configurare lo stile.

  Ad esempio, per ESLint dovresti fare quanto segue:

  1. Installa Nodo.js.
  2. Installa ESLint con il comando npm install -g eslint (npm è un installatore di pacchetti JavaScript).
  3. Crea un file di configurazione chiamato .eslintrc nella radice del tuo progetto JavaScript (nella cartella che contiene tutti i tuoi file).
  4. Installa / abilita il plugin per il tuo editor che si integra con ESLint. La maggior parte degli editori ne ha uno.

  Ecco un esempio di un file.eslintrc :

  { "extends": "eslint:recommended", "env": { "browser": true, "node": true, "es6": true }, "rules": { "no-console": 0, "indent": 2 }}

  Qui la direttiva "extends" indica che la configurazione è basata sul set di impostazioni “eslint:recommended”. Dopo di ciò, specifichiamo il nostro.

  È anche possibile scaricare set di regole di stile dal web ed estenderli invece. Vedere http://eslint.org/docs/user-guide/getting-started per maggiori dettagli sull’installazione.

  Anche alcuni IDE hanno linting incorporato, che è conveniente ma non personalizzabile come ESLint.

  Sommario

  Tutte le regole di sintassi descritte in questo capitolo (e nelle guide di stile a cui si fa riferimento) mirano ad aumentare la leggibilità del codice. Tutti sono discutibili.

  Quando pensiamo di scrivere codice” migliore”, le domande che dovremmo porci sono: “Cosa rende il codice più leggibile e più facile da capire?”e” Cosa può aiutarci a evitare errori?”Queste sono le cose principali da tenere a mente quando si sceglie e si discute degli stili di codice.

  La lettura di guide di stile popolari vi permetterà di tenersi aggiornati con le ultime idee sulle tendenze di stile del codice e le migliori pratiche.