In questa seconda lezione del video corso sul JavaScript Semplificato per il mondo Google vi parlerò di sintassi ovvero delle regole JavaScript che definiscono un programma correttamente strutturato.

Il JavaScript è molto elastico da questo punto di vista ed è proprio da questa grande libertà che voglio mettervi in guardia! Ti spiego sul campo a cosa mi sto riferendo, indicandoti il metodo che ti consiglio di seguire e mostrandoti il perché. Tutto questo, con poche regole e alcune best practice da tenere, ti consentirà di ottenere un codice pulito, facile da scrivere e da leggere ed evitare fin da subito di prendere cattive abitudini.

La prima nota sintattica che consiglio in JavaScript è quella di terminare le istruzioni con il punto e virgola. Sebbene questo non sia obbligatorio, poiché l'engine riesce a interpretare la fine di un’istruzione e quindi eseguire le operazioni correttamente, può sempre esserci il rischio di creare ambiguità e quindi malfunzionamenti che non sempre generano un errore visibile, rendendo più difficile l’identificazione dell’anomalia.

GUARDA IL VIDEO:

Cosa mostro nel video:

In JavaScript posso scrivere queste istruzioni terminandole con il punto e virgola, ma otterrei lo stesso risultato anche senza. Il fatto è che potrei scrivere quanto sopra anche in questo modo, e tutto funzionerebbe come prima… va da sé che in questa circostanza, con codici complessi, la lettura del codice da parte nostra o da chi dovrà metterci mano comincia a diventare complicata e altamente soggetta ad errori.

Il metodo da adottare, in ottica di programmazione rapida semplificata, è questo, ovvero con le istruzioni terminate dal punto e virgola. Personalmente non lo inserisco solo dopo che ho la chiusura di una parentesi graffa poiché questa di per sé funge da delimitatore.

Inserire i punti e virgola nel modo corretto consente inoltre di posizionare le istruzioni su un’unica riga. Questo è utile ad esempio sul web quando si vuole ridurre le dimensioni dei file e aumentare le prestazioni della pagina. Ad ogni modo non è un aspetto che ci interessa per le nostre finalità e che in ogni caso sconsiglio di effettuare manualmente, mantenendo invece le istruzioni distinte su ogni riga per garantire la semplicità di lettura del nostro codice. L’ho menzionato solo perché, qualora servisse in ottica di ottimizzazione, esistono software gratuiti online che effettuano queste operazioni di compressione o minimizzazione del codice con la rimozione automatica di tutti i caratteri non necessari come gli spazi vuoti, la nuova riga o i commenti. E se non si inseriscono correttamente i punti e virgola si possono ottenere effetti collaterali negativi come la generazione di un errore oppure rendere inefficace l’operazione. Ad esempio se volessi minificare banalmente questo semplice codice con il primo tool che mi viene restituito da una ricerca su Google, è facile rendersi conto che nessuna trasformazione viene applicata, a differenza del caso in cui aggiungo un punto e virgola alla fine dell’istruzione. Ma anche altri strumenti possono dare risultati inattesi: questo minificando il codice dove non è previsto il punto e virgola (si vede già che l’editor non lo digerisce ancora prima di provare a salvare) e questo se applico i punti e virgola alla fine delle istruzioni.

Inoltre, può essere più difficile eseguire il debug senza punto e virgola poiché il codice potrebbe concatenarsi insieme senza che ce ne rendiamo conto.

QUINDI: utilizzare sempre il punto e virgola.

Dagli esempi di minificazione del codice appena vista si è potuto notare che anche tutti gli spazi bianchi vengono rimossi. Gli spazi bianchi in JavaScript, infatti, non assumono significati particolari nelle espressioni. Le uniche eccezioni sono per le dichiarazioni, come quelle di variabili o di funzioni, e per gli spazi all’interno delle stringhe.

Gli spazi sono ininfluenti quando utilizzati prima e dopo il simbolo = oppure prima o dopo il ; al termine delle operazioni. Queste due righe possono essere considerate del tutto identiche, o meglio l’engine le considererà identiche.

Allo stesso modo gli spazi bianchi sono superflui anche prima o dopo le parentesi tonde o graffe, anche queste due righe di conseguenza sono uguali.

Mentre è intuitivo che tra i caratteri delle dichiarazioni sono importanti… scrivere var a=5 o scrivere vara=5 significa nel primo caso chiamare una variabile a, mentre nel secondo chiamarla vara (ovvero sarebbe uguale a dichiararla come var vara=5), il sistema non può sapere se volete effettivamente chiamare una variabile in questo modo. Questo perché anche la dichiarazione di una variabile può essere scritta con o senza la parola chiave var (delle variabili e del loro utilizzo semplificato ne parleremo nella prossima lezione, vi invito a iscrivervi al canale in modo da essere subito avvisati sull’uscita dei prossimi video).

Attenzione inoltre che il JavaScript è case sensitive per cui se scrivo var miavariabile=7 e var miaVariabile=8 (con la V maiuscola), non sto cambiando il valore alla stessa variabile bensì sto dichiarando 2 variabili distinte (eseguendo il codice infatti compaiono 2 risultati diversi, se fosse stata la stessa variabile entrambi i risultati avrebbero dato come risposta 8, che è l’ultimo valore che in questo caso la variabile avrebbe assunto). Anche di best practice su questo aspetto ne parleremo più avanti, intanto consiglio di scrivere tutto sempre minuscolo.

Tornando agli spazi bianchi, lo stesso caso di var si ha anche dopo la dichiarazione di una funzione e il suo nome (il sistema non può essere in grado di riconoscere che function, quando attaccato ad altri caratteri, non fa parte del nome che volete assegnare ad una funzione). Sono invece superflui prima o dopo le parentesi, come abbiamo già visto nell’occasione precedente.

All’interno di una stringa invece va da sé che sono importanti. Le stringhe sono puro testo per cui banalmente sarebbe come scrivere qualsiasi messaggio senza utilizzare gli spazi, nessuno lo farebbe, il risultato sarebbe illeggibile, ma direi che è decisamente intuibile.

Grande vantaggio dell’interfaccia di Apps Script e che ci viene incontro per agevolarci con queste regole di standardizzazione, è che si possono allineare tutti gli spazi bianchi e i rientri con un solo click, aprendo il menu contestuale con il tasto destro e cliccando su ‘Formatta documento’. Laddove non è stato inserito tutto attaccato il sistema provvederà autonomamente a rendere più leggibile il tutto inserendo spazi e indentazioni.

A scopo informativo, anche i ritorni a capo sono ininfluenti. Una best practice per garantire migliore leggibilità può essere quella di avere un ritorno a capo tra istruzioni simili, come appunto le dichiarazioni di variabili, due ritorni a capo (in modo da ottenere uno spazio bianco di separazione) tra istruzioni diverse dello stesso blocco, e 3 ritorni a capo (per generare 2 spazi di separazione) tra blocchi di codice distinti o funzioni diverse.

Quindi in generale, suggerisco di scrivere il codice con l’accortezza di gestire spazi bianchi, rientri e ritorni a capo come ho mostrato, per prendere l’abitudine a scrivere codice in modo più facilmente leggibile; con la consapevolezza che con la funzionalità ‘Formatta documento’ possiamo allineare il tutto in qualsiasi momento.

Quelle appena descritte non sono regole, bensì miei consigli basati sull’esperienza. Quando ritornerete dopo una settimana o un mese (a volte anche il giorno dopo...) a mettere di nuovo mano al codice, vi renderete conto che la leggibilità di quello che avete scritto è notevolmente agevolata e potrete ripartire da dove avete lasciato, senza troppe perdite di tempo.

A tal proposito prendono particolare importanza i commenti. I commenti sono fondamentali!

Vi troverete spesso in situazioni dove rileggendo il vostro codice a distanza di tempo noterete dei passaggi poco chiari. Questo succede soprattutto a chi è alle prime armi, ma non solo. Quando si sviluppa ma le idee non sono del tutto chiare oppure si integra a posteriori qualcosa che già c’era e funzionava. Quando si fa un accrocchio o ci si mette una pezza per intendersi (che non è mai un bene, ma il tempo spesso è tiranno), ma anche quando il programma evolve in termini di funzionalità e quindi dovrà essere modificato.

Quando si rilegge il codice a distanza di tempo capita spesso di notare dei passaggi poco chiari, apparentemente superflui. La tendenza in questi casi è quella di pensare che una riga o un valore cambiato in un certo punto, sia dovuto a un retaggio o qualcosa che non ha senso di esistere.

Ma cos’è questa roba? Non serve a niente… togliamola...

Mai cosa più sbagliata di questa! :D Se il codice fatto funzionava correttamente, NON TOCCATE NIENTE! Magari togliendo una semplice condizione può sembrare che non cambi nulla, ma non è così, prima o poi ci sarà un’eccezione perché se lo avete scritto all’epoca un motivo ci sarà stato. Quindi se avete un dubbio, o spendete minuti, se non ore a risalire a tutto il giro e condizioni che fa il vostro codice… oppure mettete sempre un commento, a costo di scrivere un commento per ogni riga di codice che scrivete, il tuo te stesso del futuro ringrazierà il te stesso passato.

Michele del passato: Michele del futuro ricordati che che questa riga azzera sempre la variabile altrimenti il sistema si blocca se l’utente inserisce un valore non previsto che ti arriva dalla funzione scritta sopra.

Michele del futuro: Grazie Michele del passato, ecco a cosa serviva questo controllo, sembrava quasi una dimenticanza rimasta in fase di test e stavo per toglierla, per fortuna ho letto quello che mi hai scritto :)

Impiega 20 secondi per scrivere un commento… e risparmierai 2h di tempo a capire cosa è che non funziona più...

Negli esempi appena visti ho già fatto uso dei commenti. In generale possono essere inseriti all'interno del codice per singola riga o multiriga.

Nel primo caso basterà scrivere un doppio slash, a quel punto tutto ciò che si trova dopo, purché sulla stessa riga, sarà considerato un commento ed ignorato dall’engine in fase di esecuzione. Questo tipo di commento può essere inserito su una riga vuota oppure a fianco del termine di un’istruzione.

Il commento multiriga invece prevede la presenza di 2 caratteri di apertura e 2 di chiusura, nel caso specifico slash asterisco, e asterisco slash. Tutto ciò che viene inserito all’interno sarà considerato un commento.

I commenti multiriga inoltre saranno utili per un altro scopo quando li applicherete ad un contesto Google. Nei Fogli di Google infatti, l’utilizzo di commenti multiriga permette di creare funzioni personalizzate negli Spreadsheet, che non esistono nativamente, e definire descrizione e dettaglio dei parametri al pari di una funzionalità nativa.

Ricapitolando quello che abbiamo visto in termini di best practice, indipendentemente dalla flessibilità dello strumento:

• terminare tutte le istruzioni con il punto e virgola;

• utilizzare sempre gli spazi e indentazioni per rendere il codice più leggibile (nel caso avvalersi di tanto in tanto della funzionalità offerta dall’interfaccia per formattare automaticamente il documento);

• scrivere tutti i nomi di variabili in minuscolo (questo aspetto lo rivedremo più avanti ma per il momento è uno standard che ci semplifica la scrittura di codice);

• infine.. e soprattutto… commentare, sempre, se non volete farlo ogni riga fatelo per blocchi di codice ma commentate scrivendo cosa fa il vostro programma in quel momento e perché. Mi ringrazierete :)

Con questa base possiamo iniziare ad entrare più nello specifico dello sviluppo.

Nel prossimo video parleremo di variabili. Vedremo rapidamente quali sono le tipologie e ti mostrerò come puoi semplificarti la vita utilizzandone un solo tipo, in tutte le occasioni, dandoti un consiglio fondamentale per evitarti dei grossi grattacapi :)

Lasciami un commento per farmi sapere cosa ne pensi o se hai alcuni dubbi su quanto ti ho appena raccontato in questa video lezione.

Ricordati di iscriverti al mio canale per rimanere aggiornato sull’uscita delle nuove video lezioni.
A presto, Ciao ;)

VAI alla Lezione 3: Variabili, Dichiarazioni e Ambiti

TORNA alla Lezione 1: L'interfaccia