Code smell

The term code smell was coined by Kent Beck and introduced to a wide audience in Martin Fowler's Refactoring: Improving the Design of Existing Code (1999). Fowler described smells as surface indications that usually correspond to deeper problems in the system, though they are not necessarily bugs. The metaphor draws from the idea that a bad smell in a room signals something wrong that needs attention, even if the exact cause is not immediately visible.

Smells are not formal metrics but heuristics, relying on developer intuition and experience. They often point to violations of design principles such as the Single Responsibility Principle or excessive coupling. Fowler's catalog of 22 smells includes examples like Duplicated Code, Long Method, and Feature Envy, each with suggested refactorings.

Fowler's catalog categorizes smells into groups: Bloaters (e.g., Long Method, Large Class), Object-Orientation Abusers (e.g., Switch Statements, Temporary Field), Change Preventers (e.g., Divergent Change, Shotgun Surgery), Dispensables (e.g., Comments, Dead Code), and Couplers (e.g., Feature Envy, Inappropriate Intimacy). Each smell has a characteristic symptom and a typical refactoring, such as Extract Method for Long Method or Move Method for Feature Envy.

Beyond Fowler, other authors have added smells like God Object (a class that does too much) and Magic Numbers (unexplained literals). Tools like ESLint and SonarQube automate detection of some smells, but many require human judgment.

Automated static analysis tools can identify certain code smells by pattern matching. For instance, PMD and Checkstyle flag long methods or excessive class complexity. Research has explored machine learning approaches to detect smells, using metrics like cyclomatic complexity and coupling. However, studies show that tool-based detection often yields false positives, and human review remains essential.

In agile development, code smells are often discussed during code reviews and pair programming. The concept aligns with the practice of continuous refactoring, where developers improve code incrementally. Smells are also used in technical debt assessment, as they indicate areas that may require future rework.

While Fowler's list is canonical, the term has evolved. In 2018, a systematic literature review identified over 400 distinct code smells, many domain-specific. Some smells are controversial: for example, Comments as a smell is debated, as comments can be valuable. Also, smells are not universal; a pattern considered a smell in one context may be acceptable in another, such as performance-critical code.

Notably, the concept has been extended to other artifacts: test smells (e.g., Assertion Roulette) and architecture smells (e.g., Connector Envy). The term has also entered popular culture, with developers humorously referring to 'smelly' code. A 2020 study found that code smells are often introduced during refactoring, highlighting the need for careful practice.

Refactoring

The process of restructuring existing code without changing its external behavior to improve its internal structure.

Technical debt

The implied cost of additional rework caused by choosing an easy solution now instead of a better approach that would take longer.

Static analysis

The analysis of code without executing it, often used to detect potential issues.