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. Il code smell spesso è correlato alla presenza di debito tecnico e la sua individuazione è 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, abbassandone la complessità 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 incoerenti: insiemi di nomi e identificatori incoerenti fra loro (per esempio, uso non coerente 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]- ^ a b c d Fowler et al. (1999)
- ^ Binstock (2011)
- ^ a b c J. Atwood, Code smells Archiviato il 18 gennaio 2013 in Internet Archive. presso codinghorror.com
- ^ Code comments: Good or Bad? Archiviato il 22 marzo 2016 in Internet Archive., presso tobeaile.com
- ^ You Arent Gonna Need It
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.
Voci correlate
[modifica | modifica wikitesto]Collegamenti esterni
[modifica | modifica wikitesto]- Jeff Atwood, Code smells Archiviato il 18 gennaio 2013 in Internet Archive. presso codinghorror.com
