In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express. It makes the language “sweeter” for human use: things can be expressed more clearly, more concisely, or in an alternative style that some may prefer.
Fonte: Syntactic Sugar su Wikipedia
Quando si riprende in mano del codice dopo anni che è stato scritto o quando si lavora in team è veramente importante che la sintassi usata sia la più “zuccherata” possibile.
Spesso nel mio lavoro perdo una quantità considerevole di tempo a cercare di capire cosa fa una porzione di codice perché non è stata commentata o perché il programmatore (molto spesso io stesso) ha cercato di scrivere meno linee possibili omettendo parentesi o inserendo due istruzioni sulla stessa riga.
La qualità del codice scritto dovrebbe essere anche valutata in base a quanto risulta semplice riprendere in mano il codice.
Cosa fare quindi?
Ecco qualche semplice consiglio:
Commentare
L’uso dei commenti è vitale per iniziare a documentare il proprio codice. Avere un documento esterno che descrivere il funzionamento del codice senza avere dei commenti nel codice è praticamente inutile.
// Commento singolo
/*
Commento su più righe
*/
/**
* Commento in xxxDOC style
*/
Se, per esempio, abbiamo una funzione e la vogliamo commentare in maniera utile dobbiamo fornire più informazioni possibili, inoltre alcuni IDE (es: Eclipse ) sono in grado di leggere i commenti scritti in simil JavaDoc per utilizzarli per il code completion facilitando tantissimo il lavoro.
/**
* Questa funzione pulisce una stringa
* @param String $input stringa da pulire
* @return String $output stringa pulita
*/
function pulisciStringa( string $input ) {
$output = '';
$output = trim($input);
return $output;
}
Nomi parlanti delle variabili
Più volte ho visto variabili con nomi dati a caso o contratti così tanto da non essere più comprensibili.
$ems = 12; // Non si capisce a cosa serva $etmdstu = 12; // Ancora non è chiaro // In questo caso i dubbi su a cosa serva la variabile // sono veramente pochi $etaMediaStudenti = 12;
Una istruzione una riga
A meno che non si stia facendo un esercizio di stile (in ogni caso cosa discutibile) è meglio usare la regola di 1 istruzione 1 riga.
// In caso di revisione del codice, la seconda istruzione potrebbe essere non vista $nome = $trim($nome); $nome = ucfirst($nome);
Le parentesi graffe non costano
Le graffe in molti casi delimitano blocchi di codice. Se il codice delimitato è di una sola istruzione allora alcuni linguaggi permettono di ometterle, questo però rende più complicata la lettura del codice e nel caso il programmatore metta anche più istruzioni sulla stessa riga rende il tutto un incubo.
if ( $annoInserito == 2013 )
echo "Nel 2013 sono successe un sacco di cose"; salva($annoInserito);
L’echo viene eseguita se l’if scatta, la seconda istruzione sempre.
Questo leggendo il codice velocemente non è subito comprensibile.
Invece:
if ( $annoInserito == 2013 ) {
echo "Nel 2013 sono successe un sacco di cose";
}
salva($annoInserito);
In questo ultimo caso è chiarissimo.
Concludendo
Le cose che ho scritto sono semplici e a molti potrebbero sembrare ovvie, ma vi assicuro che nei miei anni di lavoro ho incontrato diverse difficoltà che potevano essere evitate seguendo queste semplici regole.
Non auguro a nessuno di voi di ritrovarsi in una sessione RDP su una VPN “a manovella” a dover correggere attraverso notepad.exe del codice in produzione che è stato scritto da un programmatore che ha ignorato le regole base della sintassi zuccherina.