← All categories

Code Smells

Small, recognisable warning signs, and the refactorings that remove them.

A code smell is not a bug. It is a sign that the code will be harder to change than it needs to be: a method that scrolls forever, a parameter list nobody can read, a switch copied into five files, or names that need a comment to explain them.

Each smell has well-known refactorings, often mechanical ones such as extracting a method, introducing a parameter object or replacing a condition with polymorphism. The skill is spotting the smell and choosing the smallest change that removes it, without changing behaviour.

You'll recognise it when

  • Methods with comment banners separating their sections.
  • Three values that always travel together as separate parameters.
  • Booleans passed in to switch a method between different behaviours.
  • Unexplained numbers and strings in business rules.

Example

An airline books seats with a method that grew one argument at a time.

Before
book("Asha Rao", "asha@mail.in", "BLR", "DEL", 2, 1, true, false);
//                                                 ^  ^   ^     ^
//                                    adults, children, meal?, window?
After
Passenger asha = new Passenger("Asha Rao", "asha@mail.in");
Route route = new Route("BLR", "DEL");
Party party = Party.of(2).withChildren(1);

book(asha, route, party, Preferences.none().withMeal());

Why it's better: Related values travel as one named object, the call explains itself without comments, and swapping two arguments becomes a compile error instead of a wrong booking.

Ideas you'll practise

Extract MethodParameter ObjectReplace conditional with polymorphismNamed constantsGuard clausesRemove dead codeMove MethodInline unnecessary layers

Problems 21