Skip to content
Software Architecture Guide

Code Smell

Explanation

Section titled “Explanation”

A code smell is a visible hint in the code. It usually points to a deeper design problem in the system. The smell itself is not necessarily a bug. It tells you where to look closer.

Kent Beck coined the term while helping write the book on refactoring. That ties smells to refactoring: a smell shows where a cleanup may be worth considering (see the article Refactoring).

Common smells

  • Long Method: a method with too many lines of code. Around ten lines is where you start asking questions.
  • Large Class: a class that has collected many fields, methods or lines of code.
  • Long Method and Large Class belong to a group called Bloaters. These are pieces of code that have grown too big to work with.
  • Feature Envy: a method uses another object’s data more than its own. This is a coupling smell, meaning two parts of the code are tied closely together. See the article Coupling and Cohesion.
  • Middle Man: a class left as an empty shell that only passes work on to others.

Detecting smells with metrics

Tools can measure code and help flag likely smells. One metric is cyclomatic complexity. It counts the linearly independent paths through source code. McCabe developed it in 1976.

Static analysis tools inspect code and report such metrics. SonarQube, for example, reports cyclomatic complexity and cognitive complexity. Cognitive complexity rates how hard the control flow is to understand. SonarQube also counts code smells.

Link to technical debt

Smells connect to technical debt. The extra effort needed to add new features is the interest paid on internal-quality problems. See the article Technical Debt.

Example

Section titled “Example”

A team’s order-processing class has grown very large. One method in it runs far past ten lines. Another method mostly reads the customer object’s data instead of its own. A static analysis tool reports a high complexity value for the long method. The team treats these as smells and plans small refactoring steps.

Trade-offs

Section titled “Trade-offs”

A smell is only a hint. Not every flagged method is a real problem, and a metric value alone does not prove bad design. The ten-line figure is a point to start asking questions, not a hard rule. Treat tool reports as a prompt for review.

Checks

Section titled “Checks”
  • The documentation names how code smells are detected, for example through static analysis tools that report complexity metrics.
  • Known smells such as overly long methods or large classes are tracked, with refactoring planned for them.
  • Internal-quality problems found through smells are recorded as technical debt.
Section titled “Related”

Sources

Section titled “Sources”