Il Clean Code risale a Robert Cecil Martin, un con­su­len­te in­for­ma­ti­co, che nel suo libro “Clean Code: guida per diventare bravi artigiani nello sviluppo agile di software” (di­spo­ni­bi­le in inglese con il titolo di “Clean Code: A Handbook of Agile Software Craf­tsman­ship”) lo ha uti­liz­za­to come termine per definire un codice pulito. I principi del Clean Code però hanno una storia ancora più lunga e le sue origini non sono a dire il vero legate allo sviluppo di software. Di seguito vi spie­ghe­re­mo cosa rende i codici puliti, quali sono i vantaggi e come fare per scriverli in autonomia.

Cos’è il Clean Code?

Il Clean Code non è un rigido insieme di regole, definisce invece una serie di principi che con­sen­to­no di rea­liz­za­re un codice com­pren­si­bi­le in modo intuitivo e facile da mo­di­fi­ca­re. Com­pren­si­bi­le significa in questo caso che il codice è chiaro fin da subito per uno svi­lup­pa­to­re. Le seguenti proprietà sem­pli­fi­ca­no la leg­gi­bi­li­tà del Clean Code:

  • Il thread di ese­cu­zio­ne dell’intera ap­pli­ca­zio­ne è strut­tu­ra­to in maniera semplice e ordinata.
  • La cor­re­la­zio­ne tra le diverse parti del codice è evidente.
  • Il compito o ruolo di ciascuna classe, funzione, metodo e variabile è com­pren­si­bi­le im­me­dia­ta­men­te.

Inoltre, il codice è fa­cil­men­te mo­di­fi­ca­bi­le quando deve solamente essere adattato o ampliato, in questo modo è anche più semplice eliminare un errore all’interno del codice. Per questo motivo il Clean Code è veramente di facile ma­nu­ten­zio­ne. Un codice semplice da mo­di­fi­ca­re ha le seguenti ca­rat­te­ri­sti­che:

  • Le classi e i metodi sono ridotti e pos­si­bil­men­te hanno un solo compito ben preciso.
  • Le classi e i metodi sono pre­ve­di­bi­li, fun­zio­na­no come ci si aspet­te­reb­be e sono ac­ces­si­bi­li pub­bli­ca­men­te tramite API (in­ter­fac­ce) ben do­cu­men­ta­te.
  • Il codice dispone di unit test.

I vantaggi di questo tipo di pro­gram­ma­zio­ne sono evidenti: il Clean Code è in­di­pen­den­te dallo svi­lup­pa­to­re ori­gi­na­rio. Quindi, in linea di principio, ogni pro­gram­ma­to­re può lavorare con il codice, in questo modo vengono evitati i problemi che po­treb­be­ro, ad esempio, sorgere uti­liz­zan­do un Legacy Code. Anche la ma­nu­ten­zio­ne del software risulta sem­pli­fi­ca­ta, perché in questo modo i bug vengono iden­ti­fi­ca­ti e rimossi più fa­cil­men­te.

Spie­ga­zio­ne sintetica dei principi del Clean Code

Ma come si fa a scrivere un codice pulito? Nel Clean Code vanno tenuti presenti de­ter­mi­na­ti principi guida della pro­gram­ma­zio­ne. Non si tratta tanto di concrete istru­zio­ni su cosa e come pro­gram­ma­re in una de­ter­mi­na­ta si­tua­zio­ne, ma piuttosto di dare uno sguardo che rimanda alla propria espe­rien­za di lavoro sul campo come svi­lup­pa­to­re. Proprio per questo nella comunità degli svi­lup­pa­to­ri la de­fi­ni­zio­ne del si­gni­fi­ca­to concreto di Clean Code è dibattuta: quello che per alcuni pro­gram­ma­to­ri è “pulito”, per altri è ancora “poco lineare”. La per­ce­zio­ne di quanto un codice risulti pulito è quindi in parte sempre anche sog­get­ti­va. Di seguito vi pro­po­nia­mo alcuni principi con­so­li­da­ti del Clean Code, che vengono con­si­de­ra­ti ra­gio­ne­vo­li dalla maggior parte degli svi­lup­pa­to­ri.

Un codice il più semplice possibile: KISS

Il KISS (Keep it simple, stupid) è uno dei primi principi del Clean Code in ordine di tempo, è stato infatti applicato dalle forze armate sta­tu­ni­ten­si negli anni ‘60. Il KISS ricorda ai pro­gram­ma­to­ri di rea­liz­za­re un codice che sia il più semplice possibile; qualsiasi com­ples­si­tà inutile andrebbe evitata. Nella pro­gram­ma­zio­ne non c’è mai una sola via per risolvere un problema, un compito può essere espresso in linguaggi diversi e formulato con comandi dif­fe­ren­ti. Un pro­gram­ma­to­re che segue il principio KISS deve quindi sempre chiedersi se un de­ter­mi­na­to problema potrebbe essere risolto anche in maniera più semplice.

Evitare ri­pe­ti­zio­ni inutili: DRY

DRY (Don’t repeat yourself) è in un certo senso una con­cre­tiz­za­zio­ne del KISS. Un Clean Code conforme al principio DRY fa in modo che una funzione abbia una sola e univoca rap­pre­sen­ta­zio­ne all’interno dell’intero sistema.

N.B.

Il contrario di DRY è WET (We enjoy typing). Un codice viene chiamato WET quando dei doppioni inutili compaiono nel codice.

Il seguente esempio dovrebbe chiarire il principio del Clean Code: il nome utente e la password vengono ri­chia­ma­ti due volte nel codice, per essere uti­liz­za­ti per azioni diverse. Invece di pro­gram­ma­re i due processi se­pa­ra­ta­men­te, questi possono essere uniti in una sola funzione. Da un codice WET con ri­don­dan­ze si ottiene così un conciso codice DRY.

Codice WET:

//Variante A
let username = getUserName();
let password= getPassword();
let user = { username, password};
client.post(user).then(/*Variante A*/);
//Variante B
let username = getUserName();
let password= getPassword();
let user = { username, password};
client.get(user).then(/*Variante B*/);

Codice DRY:

function getUser(){
    return {
        user:getUserName();
        password:getPassword();
    }
}
//Variante A
client.post(getUser()).then(/*Variante A*/ );
//Variante B
client.get(getUser()).then(/*Variante B*/);

Togliere quello che non serve: YAGNI

Dietro al principio YAGNI (You aren’t gonna need it) del Clean Code si cela la seguente idea: uno svi­lup­pa­to­re dovrebbe inserire in un codice fun­zio­na­li­tà ag­giun­ti­ve solamente quando queste diventano ne­ces­sa­rie. YAGNI è stret­ta­men­te connesso ai metodi dello sviluppo agile dei software. Invece di partire dallo sviluppo di un progetto completo, quando si programma secondo il principio YAGNI si crea l’ar­chi­tet­tu­ra del software a piccoli step, per poter ri­spon­de­re ai problemi in maniera dinamica e mirata. Si crea quindi un Clean Code ogni­qual­vol­ta il problema di base è stato risolto nel modo più ef­fi­cien­te.

Leg­gi­bi­li­tà e con­ci­sio­ne

Il codice deve fun­zio­na­re ed essere com­pren­si­bi­le per la macchina che esegue l’ope­ra­zio­ne. Ma so­prat­tut­to nei casi in cui lavorate a un progetto con più persone, anche altri svi­lup­pa­to­ri devono poter com­pren­de­re il codice. Per questo motivo la leg­gi­bi­li­tà nello sviluppo del codice è sempre più im­por­tan­te rispetto alla con­ci­sio­ne dello stesso. Non ha senso scrivere un codice che sia molto breve, se poi gli altri svi­lup­pa­to­ri non lo capiscono. Un buon esempio di Clean Code per quanto riguarda la leg­gi­bi­li­tà è la de­no­mi­na­zio­ne delle variabili.

Il nome di una variabile dovrebbe essere sempre com­pren­si­bi­le. La seguente variabile non è chiara senza co­no­scen­ze pregresse e una spie­ga­zio­ne: 

int d;

Se viene invece viene ri­no­mi­na­ta come di seguito, la variabile si spiega da sé:

int elapsedTimeinDays;
Vai al menu prin­ci­pa­le