Code smell

In computer programming, code smell, (or bad smell) is any symptom in the source code of a program that possibly indicates a deeper problem.[1] According to Martin Fowler, "a code smell is a surface indication that usually corresponds to a deeper problem in the system".[2] Another way to look at smells is with respect to principles and quality:[3] "smells are certain structures in the code that indicate violation of fundamental design principles and negatively impact design quality". Code smells are usually not bugs—they are not technically incorrect and do not currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future. Bad code smells can be an indicator of factors that contribute to technical debt.[1]Robert C. Martin calls a list of code smells a "value system" for software craftsmanship.[4]

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

A 2015 study[1] utilizing automated analysis for half a million 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".

The term appears to have been coined by Kent Beck on WardsWiki in the late 1990s. Usage of the term increased after it was featured in Refactoring: Improving the Design of Existing Code.[5]Code smell is also a term used by agile programmers.[6]

Determining what is and is not a code smell is subjective, and varies by language, developer and development methodology. There are tools, such as Checkstyle, PMD and FindBugs for Java, to automatically check for certain kinds of code smells.

Excessive use of literals: these should be coded as named constants, to improve readability and to avoid programming errors. Additionally, literals can and should be externalized into resource files/scripts where possible, to facilitate localization of software if it is intended to be deployed in different regions.

Cyclomatic complexity: too many branches or loops; this may indicate a function needs to be broken up into smaller functions, or that it has potential for simplification.

Downcasting: a type cast which breaks the abstraction model; the abstraction may have to be refactored or eliminated.[7]

Orphan variable or constant class: a class that typically has a collection of constants which belong elsewhere where those constants should be owned by one of the other member classes.

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 this object instead.[8][9]

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.

Long method: a method, function, or procedure that has grown too large.