Editing Code smell

{{short description|Computer programming characteristic}}
In [[computer programming]], a '''code smell''' is any characteristic in the [[source code]] of a [[Computer program|program]] that possibly indicates a deeper problem.<ref name="Tufano2015">{{Cite book |chapter-url = http://www.cs.wm.edu/~denys/pubs/ICSE'15-BadSmells-CRC.pdf |doi = 10.1109/ICSE.2015.59 |isbn = 978-1-4799-1934-5|citeseerx = 10.1.1.709.6783|chapter = When and Why Your Code Starts to Smell Bad |title = 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering |pages = 403–414 |year = 2015 |last1 = Tufano |first1 = Michele |last2 = Palomba |first2 = Fabio |last3 = Bavota |first3 = Gabriele |last4 = Oliveto |first4 = Rocco |last5 = Di Penta |first5 = Massimiliano |last6 = De Lucia |first6 = Andrea |last7 = Poshyvanyk |first7 = Denys |s2cid = 59100195 }}</ref><ref>{{cite web|last1=Fowler|first1=Martin|title=CodeSmell|url=http://martinfowler.com/bliki/CodeSmell.html|website=martinfowler.com/|access-date=19 November 2014}}</ref> Determining what is and is not a code smell is subjective, and varies by [[Programming language|language]], developer, and development methodology.

The term was popularized by [[Kent Beck]] on [[WardsWiki]] in the late 1990s.<ref name="Cunningham">{{cite web |last1=Beck |first1=Kent |title=Code Smells |url=https://wiki.c2.com/?CodeSmell |website=WikiWikiWeb |publisher=Ward Cunningham |access-date=8 April 2020}}</ref> Usage of the term increased after it was featured in the 1999 book ''Refactoring: Improving the Design of Existing Code'' by [[Martin Fowler (software engineer)|Martin Fowler]].<ref>{{cite book
 | first = Martin
 | last = Fowler
 | author-link = Martin Fowler (software engineer)
 | year = 1999
 | title = Refactoring. Improving the Design of Existing Code
 | publisher = Addison-Wesley
 | isbn = 978-0-201-48567-7
 | url-access = registration
 | url = https://archive.org/details/isbn_9780201485677
 }}
</ref> It is also a term used by [[Agile software development|agile]] programmers.<ref name="In Praise Of Small Code">{{Cite web
|url= http://www.informationweek.com/architecture/in-praise-of-small-code/d/d-id/1098422
|title= In Praise Of Small Code
|first=  Andrew | last = Binstock
|publisher= Information Week
|date= 2011-06-27
|access-date= 2011-06-27}}
</ref>

==Definition==
One way to look at smells is with respect to principles and quality: "Smells are certain structures in the code that indicate violation of fundamental design principles and negatively impact design quality".<ref>{{cite book|last1=Suryanarayana|first1=Girish|title=Refactoring for Software Design Smells|date=November 2014|publisher=Morgan Kaufmann|isbn=978-0128013977|pages=258}}</ref> Code smells are usually not [[software bug|bugs]]; they are not technically incorrect and do not prevent the program from functioning. Instead, they indicate weaknesses in design that may slow down development or increase the risk of bugs or failures in the future. Bad code smells can be an indicator of factors that contribute to [[technical debt]].<ref name="Tufano2015" /> [[Robert C. Martin]] calls a list of code smells a "value system" for software craftsmanship.<ref>{{Cite book|title = Clean Code: A Handbook of Agile Software Craftsmanship|last = Martin|first = Robert C.|publisher = Prentice Hall|year = 2009|isbn = 978-0-13-235088-4|chapter = 17: Smells and Heuristics|author-link = Robert C. Martin}}</ref>

Contrary to these severe interpretations, Cunningham's original definition was that a smell is a suggestion that something may be wrong, not evidence that there is already a problem.<ref name="Cunningham"/>

Often the deeper problem hinted at by a code smell can be uncovered when the code is subjected to a short [[Feedback|feedback cycle]], where it is [[Code refactoring|refactored]] in small, controlled steps, and the resulting design is examined to see if there are any further code smells that in turn indicate the need for more refactoring. From the point of view of a programmer charged with performing refactoring, code smells are [[Heuristic (computer science)|heuristics]] to indicate when to refactor, and what specific refactoring techniques to use. Thus, a code smell is a driver for refactoring.

Factors such as the understandability of code, how easy it is to be modified, the ease in which it can be enhanced to support functional changes, the code's ability to be reused in different settings, how testable the code is, and code reliability are factors that can be used to identify code smells.<ref> Suryanarayana, Girish, Ganesh Samarthyam, and Tushar Sharma. Refactoring for Software Design Smells : Managing Technical Debt  / Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma. 1st edition. Waltham, Massachusetts ; Morgan Kaufmann, 2015. Print.</ref> 

A 2015 study<ref name="Tufano2015" /> utilizing automated analysis for half a million source code [[Commit (version control)|commits]] and the manual examination of 9,164 commits determined to exhibit "code smells" found that:

* There exists empirical evidence for the consequences of "technical debt", but there exists only anecdotal evidence as to ''how'', ''when'', or ''why'' this occurs.
* Common wisdom suggests that urgent maintenance activities and pressure to deliver features while prioritizing time-to-market over code quality are often the causes of such smells.

Tools such as [[Checkstyle]], [[PMD (software)|PMD]], [[FindBugs]], and [[SonarQube]] can automatically identify code smells.

==Common code smells==
{{OR section|date=May 2020}}
===Application-level smells===

* ''[[Duplicate code|Duplicated code]]'': identical or very similar code that exists in more than one location.{{fact|date=March 2025}}
* ''[[Shotgun surgery]]'': a single change that needs to be applied to multiple classes at the same time.{{fact|date=March 2025}}

===Class-level smells===

*  ''Large class'', or a ''[[God object]]'': a [[Class (computer science)|class]] that contains too many types or contains many unrelated methods.{{fact|date=March 2025}}
* ''Refused bequest'': a class that [[Method overriding (programming)|override]]s a method of a base class in such a way that the [[contract (software)|contract]] of the [[base class]] is not honored by the [[derived class]], violating the [[Liskov substitution principle]].{{fact|date=March 2025}}
* ''Excessive use of literals'' or ''[[Magic number (programming)|magic numbers]]'': these should be coded as named constants, to improve readability and to avoid programming errors. Additionally, [[literal (computer programming)|literal]]s can and should be externalized into resource files/scripts, or other data stores such as databases where possible, to facilitate localization of software if it is intended to be deployed in different regions.<ref>{{Cite web|url=https://maximilianocontieri.com/code-smell-02-constants-and-magic-numbers|title=Constants and Magic Numbers|access-date=2020-11-03}}</ref>{{self published inline|date=March 2025|certain=y}}
* ''[[Downcasting]]'': a type cast which breaks the abstraction model; the abstraction may have to be refactored or eliminated.<ref>{{cite web |author=Miller, Jeremy |title=Downcasting is a code smell |url=http://codebetter.com/jeremymiller/2006/12/26/downcasting-is-a-code-smell/ |access-date=4 December 2014 |url-status=dead |archive-url=https://web.archive.org/web/20190216193452/http://codebetter.com/jeremymiller/2006/12/26/downcasting-is-a-code-smell/ |archive-date=16 February 2019 }}</ref>{{self published inline|date=March 2025|certain=y}}
* ''[[Data Clump (Code Smell)|Data clump]]'': Occurs when a group of variables are passed around together in various parts of the program. In general, this suggests that it would be more appropriate to formally group the different variables together into a single object, and pass around only the new object instead.<ref>{{Cite web|url=https://martinfowler.com/bliki/DataClump.html|title=DataClump|last=Fowler|first=Martin|access-date=2017-02-03}}</ref><ref>{{Cite web|url=https://sourcemaking.com/refactoring/smells/data-clumps|title=Design Patterns and Refactoring|website=sourcemaking.com|language=en|access-date=2017-02-04}}</ref>{{Unreliable source?|date=March 2025}}

===Method-level smells===

* ''Too many parameters'': a long list of parameters is hard to read, and makes calling and testing the function complicated. It may indicate that the purpose of the function is ill-conceived and that the code should be refactored so responsibility is assigned in a more clean-cut way.<ref>{{Cite web|url=https://mcsee.hashnode.dev/code-smell-10-too-many-arguments|title = Code Smell 10 - Too Many Arguments}}</ref>{{self published inline|date=March 2025|certain=y}}

==See also==
* {{annotated link|Anti-pattern}}
* {{annotated link|Design smell}}
* {{annotated link|List of tools for static code analysis}}
* {{annotated link|Software rot}}

==References==
{{reflist|30em}}

==Further reading==
* {{Cite journal| doi = 10.1016/j.jss.2017.12.013| volume = 138| pages = 52–81| last1 = Garousi| first1 = Vahid| last2 = Küçük| first2 = Barış| title = Smells in software test code: A survey of knowledge in industry and academia| journal = Journal of Systems and Software| date = 2018}}
* {{Cite journal| doi = 10.1016/j.jss.2017.12.034| volume = 138| pages = 158–173| last1 = Sharma| first1 = Tushar| last2 = Spinellis| first2 = Diomidis |author-link2 = Diomidis Spinellis | title = A survey on software smells| journal = Journal of Systems and Software| date = 2018| url = https://zenodo.org/record/1997449}}

==External links==
* {{Cite web |title=CodeSmell |url=https://martinfowler.com/bliki/CodeSmell.html |access-date=2022-03-01 |website=martinfowler.com}}
* Boundy, David, [http://dl.acm.org/citation.cfm?id=156632 Software cancer: the seven early warning signs] or [https://www.academia.edu/2303865/Software_cancer_the_seven_early_warning_signs here], ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (April 1993), Association for Computing Machinery, New York, NY, USA

{{Subject bar|wikt=y|Computer programming}}

[[Category:Computer programming folklore]]
[[Category:Software engineering folklore]]