Non penso smetterò mai di elogiare Daniel Stenberg, l’autore del progetto open-source curl, per la qualità dei suoi blog post. Del resto, se uno è autore di uno dei software più usati al mondo, qualcosa vorrà pur dire.

L’occasione citarlo nuovamente è data dal post intitolato Decomplexification, tema a me particolarmente caro per via di quella che potremmo definire una “campagna” portata avanti da sempre sul portale che ho intitolato #abbassoilcomplesso.

Ora, basterebbe l’incipit dell’articolo per andare a casa sereni:

(Clearly a much better word than simplification.)

I believe we generally accept the truth that we should write simple and easy to read code in order to make it harder to create bugs and cause security problems. The more complicated code we write, the easier it gets to slip up, misunderstand or forget something along the line.

And yet, at the same time, over time functions tend to grow and become more and more complicated as we address edge cases and add new funky features we did not anticipate when we first created the code many decades ago.

(Decisamente un termine migliore rispetto a “semplificazione”)

Credo che ormai tutti siamo d’accordo su un concetto fondamentale: scrivere codice semplice e facile da leggere è una buona pratica, perché riduce la possibilità di introdurre bug o problemi di sicurezza. Più il codice è complicato, più diventa facile commettere errori, fraintendere qualcosa o dimenticare dettagli importanti.

Eppure, nonostante questa consapevolezza, col passare del tempo le funzioni tendono comunque a diventare sempre più complesse. Questo succede man mano che aggiungiamo nuove funzionalità — spesso insolite o impreviste — o quando ci troviamo a gestire casi limite che non avevamo considerato al momento della prima scrittura del codice… magari avvenuta decenni fa.

Una sacrosanta verità che purtroppo è per la maggioranza ignorata.

L’analisi descrive l’adozione di una metrica che si chiama Cyclomatic complexity, attraverso la quale è possibile giudicare il livello di complessità del codice C che le viene dato in pasto. In particolare c’è un programma chiamato pmccabe a cui è possibile passare dei sorgenti C e farsi dare il valore di complessità associato.

Il risultato delle analisi iniziali per il progetto curl è stato, per ammissione dello stesso Stenberg, molto brutto, ed ha portato il maintainer a proporre al team di utilizzare il limite del valore di 100 per il codice prodotto.

Ovviamente, seguendo la regola sempre valida del lead-by-example è stato proprio Stenberg a tracciare la via, prendendo il toro per le corna, e partendo così dalle funzioni più complesse destrutturandole e rendendole più semplici e comprensibili.

Il risultato finale, osservando i grafici a compendio del post è, per così dire, clamoroso:

Ed il racconto non finisce qui, poiché a compendio di queste azioni sull’esistente, è stato anche implementato un meccanismo di CI per “rimanere onesti” e continuare ad attenersi a questa autoimposta regola.

Tutto questo, in un progetto che è pubblico e open-source, e che a mio modesto modo di vedere dovrebbe essere preso d’esempio da chiunque si ritiene uno sviluppatore.

E se ve lo state chiedendo, sì, di tool per l’analisi della complessità ne esistono per tutti i linguaggi, lo so perché l’ho appena chiesto a ChatGPT 😉