Delphi/FPC

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: Tossicità iniziale: un metodo è tossico La funzione tossica evidenziata da Delphi. 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: Il risultato del refactoring: codice spostato, nomi delle variabili più significativi, separazione delle attività. 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. I nuovi valori della tossicità. I due nuovi metodi sono al di sotto della soglia di allarme. 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.

Delphi/FPC

Quando usare le dichiarazioni inline in Delphi?

Headline