Code smell: differenze tra le versioni

Versione delle 12:39, 16 gen 2013

Versione attuale delle 13:30, 30 lug 2023

(16 versioni intermedie di 11 utenti non mostrate)

Riga 1:

Nell'[[ingegneria del software]], e in particolare nel contesto dello [[metodologie agili|sviluppo agile]] e dell'[[extreme programming]],<ref name="fowlerbook"/><ref>Binstock (2011)</ref> 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.<ref name="fowlerbook">Fowler ''et al.'' (1999)</ref> 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 diIl ''code smell'' spesso è correlato alla presenza di [[debito tecnico]] e la sua individuazione è un comune metodo [[Euristica|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à).<ref name="fowlerbook"/>

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.<ref name="fowlerbook"/> 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 ==

* ''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''<ref name="codinghorror"/> 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é).<ref>[http://tobeagile.com/2009/08/20/code-comments-good-or-bad/ Code comments: Good or Bad?] {{Webarchive|url=https://web.archive.org/web/20160322113033/http://tobeagile.com/2009/08/20/code-comments-good-or-bad/ |data=22 marzo 2016 }}, presso [http://tobeagile.com tobeaile.com]</ref>

* ''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).<ref name="codinghorror">J. Atwood, ''[http://www.codinghorror.com/blog/2006/05/code-smells.html Code smells] {{Webarchive|url=https://web.archive.org/web/20130118193329/http://www.codinghorror.com/blog/2006/05/code-smells.html |date=18 gennaio 2013 }}'' presso [http://www.codinghorror.com/ codinghorror.com]</ref>

* ''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.<ref name="codinghorror"/>

* ''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".<ref>[http://xp.c2.com/YouArentGonnaNeedIt.html You Arent Gonna Need It]</ref>

== Note ==

<references/>

==Voci correlateBibliografia ==

* Andrew Binstock (2011), ''In Praise of Small Code'', «Information Week», 27 Giugnogiugno 2011.

* Martin Fowler ''et al.'' (1999), ''Refactoring: Improving the Design of Existing Code'', Addison-Wesley. ISBN 0-201-48567-2.

== Voci correlate ==

* [[Anti-pattern]]

* [[Debito tecnico]]

* [[Refactoring]]

== Collegamenti esterni ==

==Bibliografia==

* Jeff Atwood, ''[http://www.codinghorror.com/blog/2006/05/code-smells.html Code smells] {{Webarchive|url=https://web.archive.org/web/20130118193329/http://www.codinghorror.com/blog/2006/05/code-smells.html |date=18 gennaio 2013 }}'' presso [http://www.codinghorror.com/ codinghorror.com]

* 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.

{{portale|informatica}}

[[Categoria:Programmazione]]

[[Categoria:ProgrammazioneMetodologia]]

[[cs:Pachy v kódu]]

[[Categoria:Codice sorgente]]

[[de:Smell (Programmierung)]]

[[en:Code smell]]

[[es:Hediondez del código]]

[[hr:Kodni smrad]]

[[ja:コードの臭い]]

[[pl:Zapachy kodu]]

[[zh:代码异味]]