Code Smell

Pronunciation: KOHD SMEL

Updated October 3, 20262 min read

In short

A code smell is a surface sign in code that often points to a deeper design problem, even though the code still works.

What is a code smell?

The term was coined by Kent Beck and made widely known by Martin Fowler's book Refactoring, published in 1999, which catalogued smells and the refactorings that remove them. A smell isn't a bug: the program may run perfectly. It is a hint that the code will be hard to understand, change or test, and that a closer look is worthwhile.

Common smells include long methods and large classes that do too many things; duplicated code that must be fixed in several places; long parameter lists; feature envy, where a method uses another class's data more than its own; shotgun surgery, where one change forces edits in many files; primitive obsession, using plain strings and numbers instead of small types; and magic numbers with no name explaining them.

Each smell suggests specific refactorings: extract a function, introduce a parameter object, move a method to the class whose data it uses, replace a magic number with a named constant. Linters and tools such as SonarQube flag some smells automatically, and code review is where most of them are noticed and discussed.

A common misconception is that every smell must be removed. Smells are heuristics, not rules: a long function that reads clearly from top to bottom may be better left alone, and removing duplication too early can create the wrong abstraction. The point is to notice the signal and decide deliberately, ideally with tests in place before refactoring.

Key takeaways

A code smell is a sign of a likely design problem, not a bug.
Kent Beck coined the term; Fowler's Refactoring (1999) popularized it.
Long methods, duplication and long parameter lists are classic smells.
Each smell suggests specific refactorings to fix it.
Smells are heuristics: judge each one in context.

Example

A smell and its refactoring (JavaScript)javascript

// Smells: magic numbers, duplicated logic, long parameter list
function price(base, isMember, isHoliday, country, couponCode, quantity) {
  let total = base * quantity;
  if (isMember) total = total * 0.9;
  if (isHoliday) total = total * 0.9;
  if (country === "TR") total = total * 1.2;
  if (country === "DE") total = total * 1.19;
  return total;
}

// Refactored: named constants, one option object, a lookup table
const MEMBER_DISCOUNT = 0.9;
const HOLIDAY_DISCOUNT = 0.9;
const VAT = { TR: 1.2, DE: 1.19 };

function priceFor({ base, quantity, member = false, holiday = false, country }) {
  let total = base * quantity;
  if (member) total *= MEMBER_DISCOUNT;
  if (holiday) total *= HOLIDAY_DISCOUNT;
  return total * (VAT[country] ?? 1);
}

Readers ask

Is a code smell a bug?

No. Code with smells can work correctly. A smell indicates that the code may be hard to maintain or extend, which makes future bugs more likely.

What are the most common code smells?

Long methods, large classes, duplicated code, long parameter lists, feature envy, shotgun surgery, primitive obsession, magic numbers, dead code and comments that explain confusing code instead of the code being made clearer.

How do you fix a code smell?

With a matching refactoring, such as extracting a function, introducing a named constant or moving a method, done in small steps with tests to confirm the behavior doesn't change.