Tossicità del codice in Delphi: come riconoscerla
Tra gli strumenti che Delphi mette a disposizione, la misura della tossicità del codice si presta molto bene a un refactoring veloce ed efficace del codice.
Gli strumenti che Delphi mette a disposizione per migliorare la qualità del codice sono spesso trascurati. Tra questi, il tool che calcola la tossicità dei metodi è un buon punto di partenza per capire le regole che sono alla base della buona scrittura di codice.
Scrivere programmi è facile; scriverli bene no. Per molti il concetto di “buona scrittura” è soggettivo, ma ci sono molti sistemi per valutare la bontà di un lavoro. Delphi ne mette a disposizione alcuni, tra i quali il più immediato è senz’altro la misura della tossicità (menù Project|Method Toxicity Metrics) .
Delphi contro la tossicità del codice
La tossicità del codice è una misura della complessità del codice e, come tutte le misure, si basa su criteri in qualche modo soggettivi; il suo valore, però, è indiscutibile. Lo strumento fornito da Delphi non usa tutti i criteri previsti, ma un loro sottoinsieme piuttosto efficace.
Lunghezza delle procedure
La prima misura di complessità è la lunghezza delle procedure: più una procedura è lunga, meno è comprensibile. Può sembrare un’affermazione banale, ma non è così: ancora oggi, molti programmatori preferirebbero lavorare su una procedura lunga ma lineare che su molte procedure. Spezzare il codice, però, porta almeno due vantaggi:
- Facilita il test, permettendo di verificare il funzionamento di ogni singola procedura in modo approfondito;
- Facilita la lettura, se si danno alle procedure dei nomi significativi.
Ciò detto, è difficile determinare quale sia la lunghezza ideale di una procedura. Alcuni, con ottimo pragmatismo, sostengono che è quella che consente di leggere la procedura stessa senza scorrere lo schermo! Erik dörnenburg suggerisce una lunghezza massima di 30 righe; altri si fermano a 20. Secondo noi, superare le 20 righe autorizza a sospettare che qualcosa non va, ma superare le 25 conferma che proprio non ci siamo.
Numero di parametri
Anche il numero di parametri di una funzione è un eccellente indicatore di complessità, sul quale però gli esperti si dividono. A livello intuitivo, appare chiaro che tanto più sono i parametri, tanto meno sarà chiaro il codice che li deve elaborare. Anche a livello tecnico, però, ci sarebbe un motivo per non eccedere: più di tre parametri diminuirebbero l’efficienza del compilatore.
Quale numero massimo di parametri tollerare? Noi abbiamo scelto tre; altri hanno idee più restrittive, ma nella VCL ci sono funzioni con cinque e anche sei parametri. Usare il buon senso, a volte, aiuta più di qualsiasi metrica: meno parametri ci sono e più il codice è semplice, ma non deve diventare mai semplicistico.
Profondità degli if
Il terzo criterio è la profondità degli if annidati tra loro. Spesso, soprattutto quando si devono fare scelte in base a valori non enumerabili, come string, è spontaneo ricorrere all’uso di più if annidati, ma la chiarezza del codice ne è sicuramente compromessa. Ciò comporta una maggior difficoltà a capire la logica dell’applicazione e può portare a errori difficilmente individuabili.
Per quanto a volte sia difficile, è bene usare questa misura per rivalutare la bontà del proprio codice. La funzione IfThen può migliorare la chiarezza del codice, ma attenzione: a quanto ci risulta, il suo uso non influenza la misura sulla profondità degli if. In altre parole, annidare if … then cinque volte darà una misura 5, mentre annidando cinque IfThen il risultato sarà 0.
Complessità ciclomatica
La complessità ciclomatica di una sezione di codice è il numero di cammini linearmente indipendenti attraverso il codice sorgente. Se state per passare al paragrafo successivo, fermatevi: è un concetto davvero importante!
La sua misura, infatti, è legata al numero di decisioni che la procedure deve prendere; in parole povere, istruzioni condizionali e cicli. Se tale numero è elevato, probabilmente relative scelte vanno separate e implementate in apposite procedure. Un basso valore di questa misura è l’obiettivo che tutti si dovrebbero porre per abbassare la tossicità del codice. Sarete sorpresi dai benefici che apporterete al vostro codice, anche in rapporto ai punti precedenti!
La tossicità del codice
L’ultimo valore che il tool di Delphi ci offre è la sintesi dei precedenti: la tossicità del codice esaminato. Una misura maggiore di 1 indica problemi che andrebbero affrontati subito; misure inferiori sono invece soddisfacenti.
Come abbassare la tossicità del codice
Per concludere, ecco un piccolo esempio di quanto sia facile abbassare la tossicità del codice. L’esame di un progetto evidenzia una funzione tossica:
Si opera un intervento di refactoring, spostando il contenuto del ciclo in una funzione esterna. Isolando una parte del codice, è stato più facile anche migliorare la chiarezza complessiva:
Nel metodo riscritto, è più facile capire che la parte iniziale implementa il valore di default e la verifica delle pre-condizioni. Appare evidente, poi, che ogni token della stringa SQL è tradotto in linguaggio umano.
In seguito, anche la complessità della nuova funzione sarà abbassata usando TDictionary per diminuire sia la profondità degli if, sia la complessità ciclomatica. Ciò porterà a livelli ancora migliori la qualità del codice e faciliterà la scrittura dei test case automatici.
Ma descrivere questa operazione esula dagli scopi di questo articolo. Quanto visto, infatti, dovrebbe bastare a convincerci che abbassare la tossicità del codice è un’operazione semplice, che non richiede grosse conoscenze teoriche, ma che può portare grandi benefici al nostro lavoro.
L'autore
