5 consigli per scrivere codice migliore

Qualche tempo fa, curiosando su Quora, mi sono imbattuto in una domanda che recitava più o meno così:

Quali sono alcune delle cattive abitudini di programmazione di cui ogni programmatore dovrebbe essere a conoscenza per evitarle?

Quesito prolisso e un po’ vago, che lascia spazio a differenti interpretazioni…

L’idea per questo post mi è venuta proprio mentre cercavo di dare una risposta alla domanda in questione.

Ho pensato alla mia personale esperienza e a quello che mi è capitato di vedere in circa dieci anni di lavoro in team. E ho provato a ribaltare la domanda in questo modo:

Quali sono alcune buone abitudini che ogni programmatore dovrebbe applicare per scrivere codice migliore?

A mio parere, la chiave di tutto sta nella semplicità e nella leggibilità.

Rimango infatti dell’idea che fin tanto che il codice sarà scritto da umani, esso debba essere, prima di tutto, comprensibile agli umani.

Ecco allora la mia personalissima lista di buone abitudini (o best practice, come piace dire ai più ganzi) per scrivere codice migliore.

0. Immagina sempre di lavorare in gruppo

Questo punto è forse il più importante. Si tratta in realtà di una premessa che, in qualche modo, giustifica tutti gli altri consigli che andrò ad elencare.

Difficilmente, in ambito lavorativo, ci troveremo a lavorare completamente da soli su un progetto:

  • potremmo lavorare in team, con altri colleghi;
  • la versione 2.0 del software che stiamo attualmente sviluppando potrebbe essere affidata, in futuro, a qualcun altro;
  • potremmo dover rimettere mano ad un progetto scritto da noi stessi molto tempo prima (e spesso sarà come lavorare su codice scritto da uno sconosciuto…)

Quale che sia la nostra situazione, dovremmo sforzarci sempre di scrivere codice leggibile e quanto più comprensibile agli altri e a noi stessi.

1. Assegna nomi chiari a variabili e metodi

Provate a leggere questo frammento di codice:

int metodo(){
  var a = (eSup - eInf) / dimGen;
  proc(a);
  return a;
}

Ci avete capito nulla? Io no…

Qual è la funzione di metodo? Cosa rappresenta la variabile a? E perché viene (presumibilmente) processata da proc?

Ovviamente ho esasperato un po’ la questione, ma il messaggio che voglio trasmettere è: usare sempre nomi comprensibili per variabili, metodi e classi.

Benché sia preferibile utilizzare nomi brevi per evitare codice troppo verboso, ciò non deve inficiarne la chiarezza.

Chiunque metta mano al nostro codice dovrebbe essere in grado di capire rapidamente cosa rappresenta ogni elemento all’interno di esso.

2. Ricordati di commentare il codice

I commenti sono una delle cose più utili e più sottovalutate quando si scrive codice.

Mentre creiamo le nostre classi e i nostri metodi, tutto ci sembra estremamente chiaro… quindi perché perdere prezioso tempo a commentare la variabile x quando posso lavorare a qualcosa di più divertente?

La verità è che non è tempo sprecato, piuttosto un “investimento a lungo termine”.

Non serve scrivere poemi (altrimenti si rischia di generare solo più confusione).

Semplicemente, quando riteniamo che una parte del nostro codice non sia sufficientemente autoesplicativa, basta aggiungere qualche riga che descriva meglio cosa dobbiamo aspettarci da essa.

3. Indentazione, indentazione, indentazione!

Un’altra cosa che odio è il codice non formattato correttamente (probabilmente perché copia-incollato da qualche forum o blog e lasciato così com’è…)

Eppure la maggior parte degli IDE permette di formattare il codice con una semplice combinazione di tasti. Basta così poco…

Un codice ordinato è già molto più comprensibile, poiché riusciamo subito ad individuare molte delle strutture base: cicli, classi, metodi, ecc.

Vorrei fare personalmente i complimenti al creatore di Python, che ha reso l’indentazione un elemento required, significativo, nella sintassi del suo linguaggio.

Ecco: qualunque linguaggio di programmazione stiate usando, immaginate sempre di lavorare in Python.

4. Non mettere troppe “cose” nello stesso posto

Quando progettiamo le nostre applicazioni dovremmo sempre seguire il principio di Separation of concerns.

In breve, significa che è buona norma suddividere la logica di un’applicazione in unità indipendenti, ognuna con un compito ben preciso.

Questo approccio, oltre a favorire moltissimo il riutilizzo del codice all’interno del progetto, consente di “spezzare” la complessità in parti più semplici. Ogni elemento avrà la sua “responsabilità”, facilmente verificabile e debugabile.

Nella realtà dei fatti, molti sembrano ignorare questo principio e non è inusuale vedere mega-funzioni o classi che fanno… tutto.

In conclusione

In questo post abbiamo parlato di semplicità, di leggibilità, di chiarezza. Concetti che sembrano banali, quando si parla di programmazione, ma che spesso tendiamo a perdere di vista.

Non ho di certo inventato io l’acronimo KISS (Keep it simple, stupid), che ci ricorda come, nei sistemi complessi, le cose tendano ad incasinarsi spontaneamente.

Sempre meglio, dunque, non aggiungere complessità “superflua” ed evitabile. Piuttosto sforziamoci di trovare una soluzione semplice anche al problema più ostico. E so che non è facile… :-)

Buon lavoro e a presto,

David