Leggibilità e qualità algoritmica del codice…

Esistono molte metriche, molti parametri di giudizio per determinare la qualità del codice. In realtà cosa sia la qualità non è chiaro però è certo che, nel caso del codice, basta un’occhiata ad un listato per capire “dalla forma con cui appare” se si tratta di qualcosa di scritto bene o raffazzonato.

Sono ormai sempre più convinto che ci sia una relazione netta fra leggibilità del codice e sua qualità “algoritmica” di base, ossia vanno di pari passo fra loro. In altri termini è molto difficile che un codice scritto (e che appare) in malo modo sia anche corretto/pulito algoritmicamente. Non parliamo poi di ottimalità e efficienza.

Questo perchè chi investe tempo nel progettare bene le cose poi generalmente trova più semplice implementarlo mentre iniziare a scrivere codice senza “un’idea di fondo” di solito genera incoerenza fra le parti e, di riflesso, poca leggibilità.

Costi a confronto

Scrivere codice “pulito” apparentemente costa inizialmente di più della soluzione di comodo, scritta in fretta e furia per risolvere all’istante un problema contingente. Ma sfortunatamente se quel progetto avrà uno sviluppo prolungato nel tempo – e ragionevolmente l’avrà – allora scriverlo male costerà doppio (o più) sul lungo periodo rispetto al farlo una sola volta e immediatamente bene.

In realtà il discorso vale anche sul breve/brevissimo periodo, tanto che la scusa del “è scritto così per la fretta di consegnare” non ha mai ragione di sussistere: per esperienza il costo reale sotto forma di tempo del progettare+implementare è sempre inferiore a quello dell’implementare direttamente qualcosa per poi subirne a lungo le conseguenze.

Inoltre, a meno di “ritardi già in partenza“, sono ragionevolmente sicuro che chiunque preferisca aspettare qualche giorno di più (dico giorni non mesi o anni!) ed ottenere un prodotto “rock-solid” che ritrovarsi con un prodotto “completo-a-metà“, realisticamente usabile solo dopo qualche mese e a forza di patch.

In altri termini, non concordo con l’idea del “dare al cliente quello che chiede, subito“. Ok, questo è lo scopo ultimo del gioco, ma ogni gioco ha le sue regole…

Leggibilità come valore aggiunto

In virtù di quanto detto sopra, fare le cose per bene tende a rendere il codice così leggibile da essere facilmente modificabile e quindi manutenibile.

Un utile fatto che ho imparato durante gli anni in Università è che sforzarsi di scrivere codice leggibile fin da subito paga sempre, anche a costo di dover difendere questa scelta dagli attacchi di quella specie di “ammalati di fretta” che vorrebbero concludere prima ancora di aver iniziato.

La leggibilità permette di stanare più facilmente bug di qualunque tipo nonchè di “rinfrescarsi” la memoria – quando serve – con una semplice lettura.

Sfortunatamente non tutti lo capiscono. Nel corso del tempo ho (ahimè) conosciuto persone che han scritto codice “da cani” con la giustificazione esplicita del “così lo capisco solo io e nessuno me lo copia o me lo ruba“. Scusa ridicola: chi sano di mente ruberebbe mai uno spaghetti code?

Allo stesso modo un codice ben fatto è rivendibile com’è, ha cioè un suo valore intrinseco che perdura per un certo periodo di tempo (le tecnologie si evolvono, per cui ha un certo valore che però scema nel tempo).

Trucchetti utili

Altro trucchetto che si impara frequentando le “persone giuste” è scrivere codice che appaia il più possibile come un discorso in linguaggio naturale (in inglese normalmente) e non come un ammasso di simboli incomprensibili.

Altra cosa che non troverete in giro: ogni commento che mettete è una sconfitta per voi e per il vostro codice. I commenti dovrebbero contenere informazioni sul perchè fate una scelta o dovrebbero chiarire punti di non immediata comprensione. Sono dell’idea che un codice ben scritto sia tanto leggibile quanto immediatamente comprensibile, anche senza commenti accessori.

Un piccolo esempio: nomi di variabile. Se un linguaggio come il C permette identificatori lunghi/lunghissimi per le variabili, perchè usare sempre (per pigrizia) nomi di 2-3 lettere ovunque? Poi bisogna aggiungere anche dei commenti per ricordarsi cosa fanno quelle variabili, quando invece il significato ed il comportamento delle variabili può comodamente essere autoesplicativo.

Con i moderni IDE dotati di autocompletamento e di funzioni di replace avanzati e a livello di intero progetto, che senso ha usare variabili tipo “int f1; // first field” invece di “int firstField;“?

Ora la differenza vi sembrerà ridicola ma se quella variabile (f1) finisce insieme a molte altre in una formula, debuggare quest’ultima diventa più difficile rispetto alla forma estesa (firstField) perchè il cervello deve “tradurre” passo per passo – come un compilatore – i nomi ristretti nel loro significato prima di applicare la formula. Questo ogni volta che quella formula viene riletta!

Questo è solo un piccolo esempio, ma quante volte capita di cedere alla pigrizia e usare nomi illeggibili/non-mnemonici/incomprensibili?

La pigrizia è pericolosa e uno sviluppatore dovrebbe evitare i pericoli. Per cui…

Che ne pensate?