Mi piace la navigazione attraverso le linee guida. Di solito ci sono delle regole ovvie, quelle che sembrano bizzarre e ci sono anche quelle gemme nascoste che non avevano scoperto prima.
Purtroppo, poche aziende hanno il coraggio di pubblicare le loro linee guida interne. La BBC ha rivelato dei documenti nel 2010, ma Google ha finalmente rilasciato le guide di stile che l’azienda usa per i progetti di interni.
Le regole sono previste per C++, Objective C, Python, XML, ed R—; ma siamo interessati all’HTML, CSS e JavaScript. I documenti sono piacevolmente brevi. Ho visto troppe volte sviluppatori che sono tenuti a imparare le mille e uno regole arcane e soggettive che mostrano una tantum la conoscenza dello scrittore, piuttosto che impartire utili consigli.

HTML
Ci sono poche sorprese nelle linee guida per HTML:

  • HTML5 semantico come text/html;
  • separa il markup, lo styling e lo scripting;
  • convalida il markup, quando possibile;
  • utilizza fall-backs (piano alternativo) quando le tecnologie come canvas non sono supportati-

Google consiglia di radare ogni byte: i files devono avere la codifica UTF-8, gli spazi vuoti all’inizio e alla fine della strinaga devono essere tolti (trimmed) e si dovrebbe evitare riferimenti a entità come ad esempio e . Raccomandano inoltre di omettere strutture opzionali e i tag di chiusura, come ad esempio:

Copia codice

          <!DOCTYPE html>
          <title>Saving money, saving bytes</title>
          Qed.
Sarei per salvare i pochi bytes, ma continuo a preferire la più rigorosa sintassi XHTML.
Stranamente, Google consiglia il rientro con due spazi, piuttosto che con il tab. Ma qui non si utilizza per due volte la quantità di caratteri di spaziatura che si ha bisogno?
CSS
Le linee guida per i fogli di stile sono dominati da ulteriori tecniche di best practice e di bytes al risparmio:

  • usare i CSS validi per non avere a che fare con dei bug o sintassi proprietarie (vendor prefixes);
  • utilizzare l’ID e i nomi di classe brevi, ma assicurarsi che non siano criptiche o di presentazione (ad esempio #blue-button);
  • prendere in considerazione nomi con prefissi per progetti di grandi dimensioni, per es #xyz-help, .xyz-colonna;
  • semplificare i selettori quando possibile, per esempio #esempio, piuttosto che ul#esempio;
  • utilizzare notazioni sintassi abbreviata;
  • non utilizzare le virgolette nei valori url() o unità dopo uno zero;
  • utilizzare notazione esadecimale breve del colore #abc piuttosto che #aabbcc;
  • terminare ogni dichiarazione con un punto e virgola (anche l’ultima);
  • evitare lo hack del browser.

Google suggerisce di omettere gli zeri iniziali dalle misure, come ad esempio .5 em. Si risparmia un carattere, ma io preferisco il codice dove è più facile la scansione.
La guida raccomanda una nuova riga per ogni virgola del selettore che si applica ad un blocco. Sono tendenzialmente d’accordo, anche se sono colpevole di usare lunghi elenchi di stringhe di selezione.
Infine, si afferma che le dichiarazioni di proprietà dovrebbero essere in ordine alfabetico, ad esempio,

Copia codice

#esempio
{
  border: 1px solid #000;
  border-radius: 6px;
  display: block;
  font-family: sans-serif;
  margin: 1em;
  outline: 0;
  padding: 10px;
  text-align: center;
}
Personalmente, preferisco ordinare le proprietà per blocchi correlati, come dimensioni, font, allineamento del testo, spaziatura, margini, colore, sfondo, bordi e proprietà varie. Forse confonderebbe alcuni sviluppatori, ma ho usato il metodo per molti anni e lavora bene.
JavaScript
Comprensibilmente, le linee guida per lo JavaScript sono più lunghe, ma ci facilita la rilettura dei principi fondamentali:

  • utilizzare sempre var per dichiarare le variabili;
  • terminare sempre le linee con un punto e virgola;
  • utilizzare le caratteristiche standard piuttosto che i non-standard;
  • utilizzare i caratteri camelCaseNames e le costanti in maiuscolo, evitare l’uso della parola chiave const che non è supportato in IE;
  • utilizzare tecniche (namespacing) spazi di nomi;
  • evitare l’uso di eval() tranne che per la deserializzazione (stranamente, JSON.Parse non è menzionato come alternativa);
  • evitare l’uso di with() sugli oggetti e su for-in con gli array;
  • utilizzare array e oggetti letterali, piuttosto alle dichiarazioni dettagliate;
  • essere a conoscenza delle regole e truthy e falsy (le espressioni non booleane che possono essere trattate come tale);
  • non usare i commenti condizionali di IE nel codice JavaScript;
  • non modificare i prototipi degli oggetti incorporati – che è un peccato visto che è una delle funzioni JavaScript più potente, ma si sa che portano a problemi;
  • utilizzare li chiusure (closures) con attenzione e non introdurre riferimenti circolari;
  • allo stesso modo, fare attenzione a usare ‘this

C’è una raccomandazione insolita: non utilizzare le funzioni all’interno dei blocchi, ovvero scrivere:

Copia codice

if (x) {
  var foo = function() {}
}
piuttosto che:
Copia codice

if (x) {
  function foo() {}
}
La seconda sintassi è utilizzata in tutto il mondo. Funziona senza problemi ma non è valido per ECMAScript.
Il documento menziona anche che oggetti avvolti (wrapper) non dovrebbero essere mai usati per le primitive a meno che non siate dei typecasting. Questo può portare a risultati imprevisti, quali:
Copia codice

var x = new Boolean(false);
if (x) {
  // qui codice da valutare
}
Infine, per la guida è necessario utilizzare le virgolette singole (‘) a preferenza dei doppi apici (“) quando si delimitano le stringhe, perché possono contenere attributi in HTML. Io uso le virgolette singole per stringhe statiche in PHP, quindi forse sto diventando esigente!
 
Il miglior consiglio appare alla fine del documento: essere coerenti. Gli sviluppatori raramente sono d’accordo con tutte le linee guida di programmazione e seguono le proprie regole. Ma no rende la vita più facile per gli altri che cercano di leggere il codice o quando si torna ad esso sei mesi dopo.
Sei d’accordo con le linee guida di Google? La vostra azienda vi costringe a seguire strane pratiche di sviluppo?