Clean Code: i nomi

Benvenuti al secondo episodio della mia serie di articoli sul clean code. Nelle puntate precedenti:
Episodio 1: cosa significa Clean Code

Perché dovremmo scrivere del clean code? A questa domanda, se qualcuno se la sta facendo, rispondo prima con un video:

Le parole sono importanti (così come i nomi). Adesso rispondo alla domanda di prima con un’altra domanda: per chi scriviamo il codice? Risposta sbagliata: “per il computer”. Il computer, o smartphone, o quel che è, se ne straciccia di come avete scritto il vostro codice. Per lui avete scritto una serie di 0 e 1. Risposta giusta: “per gli esseri umani”. Quando chi mantiene il codice (o anche la persona stessa che l’ha scritto, magari dopo una settimana) si trova un sorgente da correggere la prima cosa che fa è capire cosa fare, e per capire cosa fare deve capire qual era l’intento, lo scopo, di una porzione di codice. Qui c’è la risposta alla prima domanda:

“Perché dovremmo scrivere del clean code? Per comunicare (uno scopo, un intento)”

I nomi

Può sembrare una stupidaggine (specie se alle prime armi, ma anche dopo), ma un nome significativo per una variabile, un metodo, una classe e via dicendo migliora decisamente la vita del povero programmatore, che esso sia l’autore del codice o chi lo revisiona. Un esempio pratico:

List<int> l = new List<int>{1,1,2,3,5,8,13,21};
int sq = 0;
for(int i = 0; i<l.Length; i++)
    sq+=l[i]*l[i];
return sq;

So già cosa vi state chiedendo: “cosa è questa roba?”. Spero di aver colto nel segno: senza dei nomi decenti ci vuole un po’ per capire quali erano le intenzioni del programmatore, anche per queste cinque righe. Vediamo come farlo meglio:

List<int> firstEightFibonacciNumbers = new List<int>{1,1,2,3,5,8,13,21};
int sumOfSquares = 0;
for(int i = 0; i<firstEightFibonacciNumbers.Length; i++)
    sumOfSquares +=firstEightFibonacciNumbers[i]*firstEightFibonacciNumbers[i];
return sumOfSquares;

Stiamo sommando i quadrati dei primi 8 numeri della successione di Fibonacci. Sarete d’accordo con me se affermo con una certa convinzione che all’inizio non si capiva benissimo, e questo è un codice giocattolo. Pensate cosa sarebbe successo in un codice del mondo reale.

Il messaggio qui è: scegliere un nome in base alle intenzioni dell’oggetto (qui inteso come come oggetto della OOP, ma come variabile, metodo, classe, enumerazione, tutto ciò che è nominabile (ad eccezione dell’Innominato, forse). A cosa serve questa variabile? Cosa fa questo metodo? Cosa c’è in questa classe? Un nome dovrebbe fornirvi di getto questa risposta senza andare a vedere dove è usata, il su codice, tutto il codice che contiene, rispettivamente. Non devo andare a mettere le mani nel motore per sapere che quello è il componente della macchina che la fa muovere. Di seguito vi mostro qualche linea guida per la scelta di un buon nome (magari opinabili, non sono certo il custode della verità assoluta).

Abbreviazioni

Le abbreviazioni sono il male (non proprio il male assoluto, perché ci sono dei contesti in cui sono tollerabili), ma restano sempre il male. Immaginate cosa succederebbe se io avessi iniziato questo articolo così:

“In questo A parleremo di B e di come fare a scrivere un C comprensibile”.

Cosa diamine sono A, B e C? Non penso sia importante, perché un articolo così l’avreste chiuso all’istante, e un giornale scritto così l’avreste buttato, e perfino nell’indifferenziato, perché ne avreste pochissimo rispetto. Allora perché nel codice questo lo accettiamo? Probabilmente per pigrizia, o perché in tanti sono rimasti agli anni ’80, quando Intellisense non esisteva (e non era neanche un’ipotesi) e un nome lungo era complicato da scrivere e quindi spianava la strada a errori di compilazione. Ma siamo nel 2018 man, dilly ding dilly dong! Non vorrete mica che un codice incomprensibile inizi ad essere chiamato col vostro nome, no? “Eh, questa è una Parisata”.

Come vi mostrerò un nome ben scelto spiana la strada a tutto, a cominciare dall’avere una classe o un metodo coeso, e che fanno una cosa sola. Tutto qui? Beh, classi e metodi coesi spianano la strada alla testabilità, e la testabilità spiana la strada al debug, e così via.

Se vi ho convinti e l’articolo vi è piaciuto non esitate a contattarmi sui miei profili social (trovate i link qui accanto) oppure, se preferite, offritemi un caffè (chi mi conosce sa che sono un caffeinomane).

Pierpaolo Paris

Sono uno dei tanti che sono entrati nel girone infernale di Ingegneria Informatica, e che poi ne è anche uscito. Attualmente lavoro come sviluppatore presso una società di consulenza. Ogni tanto mi diletto con la fotografia.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *