Code smell

Da Wikipedia, l'enciclopedia libera.

Nell'ingegneria del software, e in particolare nel contesto dello sviluppo agile e dell'extreme programming,[1][2] l'espressione code smell (letteralmente "puzza del codice") viene usata per indicare una serie di caratteristiche che il codice sorgente può avere e che sono generalmente riconosciute come probabili indicazioni di un difetto di programmazione.[1] I code smell non sono (e non rivelano) "bug", cioè veri e propri errori, bensì debolezze di progettazione che riducono la qualità del software, a prescindere dall'effettiva correttezza del suo funzionamento. L'individuazione di code smell è un comune metodo euristico usato dai programmatori come guida per l'attività di refactoring (ovvero l'esecuzione di azioni di ristrutturazione del codice volte a migliorarne la struttura senza modificarne le funzionalità).[1]

Nella letteratura sul refactoring esistono numerosi elenchi di code smell; il più noto e influente è quello proposto da Martin Fowler nel suo celebre libro sul refactoring.[1] Sia nell'elenco di Fowler che in altri, i code smell non sono mai definiti in termini assoluti, e la loro identificazione comprende sempre un elemento di giudizio soggettivo da parte del programmatore.

Esempi di code smell[modifica | modifica wikitesto]

  • Codice duplicato, uguale o pressoché uguale, in diverse sezioni di codice (viola il principio Don't Repeat Yourself).
  • Metodo troppo lungo.
  • Classe troppo grande.
  • Lista di parametri troppo lunga (per metodi o funzioni).
  • Feature envy[3] o data envy ("invidia dei dati"): una classe che usa massicciamente i servizi o i dati di un'altra.
  • Costanti magiche: valori letterali (numeri, stringhe) che appaiono direttamente ("cablati") nel codice.
  • Espressioni complesse di basso livello (per esempio aritmetiche, di manipolazione di stringhe, ...).
  • What comments ("commenti cosa"): commenti che spiegano cosa fa una certa porzione di codice (sintomo che il codice non è sufficientemente chiaro di per sé).[4]
  • Nomi oscuri: nomi e identificatori (di variabili, attributi, classi, ...) che non chiariscono il significato inteso dell'entità corrispondente.
  • Nomi inconsistenti: insiemi di nomi e identificatori inconsistenti fra loro (per esempio, uso inconsistente di maiuscole e minuscole).[3]
  • Dead code ("codice morto"): porzioni di codice che non sono usate (e non vengono cancellate), contribuendo al costo di manutenzione del codice senza produrre alcun beneficio.[3]
  • Generalità speculativa: codice scritto in una forma più generale del necessario per poter essere eventualmente applicato in futuro in contesti più ampi. L'extreme programming ha una specifica regola contro questa pratica, "You Aren't Gonna Need It" ("non ne avrai bisogno"): "implementa sempre le cose quando ne hai effettivamente bisogno, mai quando prevedi di averne bisogno".[5]

Note[modifica | modifica wikitesto]

  1. ^ a b c d Fowler et al. (1999)
  2. ^ Binstock (2011)
  3. ^ a b c J. Atwood, Code smells presso codinghorror.com
  4. ^ Code comments: Good or Bad?, presso tobeaile.com
  5. ^ You Arent Gonna Need It

Voci correlate[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]

Bibliografia[modifica | modifica wikitesto]

  • Andrew Binstock (2011), In Praise of Small Code, «Information Week», 27 giugno 2011.
  • Martin Fowler et al. (1999), Refactoring: Improving the Design of Existing Code, Addison-Wesley. ISBN 0-201-48567-2.