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.
- 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:
<!DOCTYPE html>
<title>Saving money, saving bytes</title>
Qed.
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?
- 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 cheul#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,
#esempio
{
border: 1px solid #000;
border-radius: 6px;
display: block;
font-family: sans-serif;
margin: 1em;
outline: 0;
padding: 10px;
text-align: center;
}
- 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 sufor-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:
if (x) {
var foo = function() {}
}
if (x) {
function foo() {}
}
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:
var x = new Boolean(false);
if (x) {
// qui codice da valutare
}
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?
Ancora nessun commento