Definition: Surface-level indicator in source code that suggests a deeper design problem, without necessarily being a bug.
— Source: NERVICO, Product Development Consultancy
What is a Code Smell
A code smell is an indicator in source code that suggests an underlying design problem. It is not a bug: the code works correctly, but its structure indicates something could be improved. The term was coined by Kent Beck and popularized by Martin Fowler in his book “Refactoring.” Code smells are symptoms that point toward areas where technical debt is accumulating.
How it works
Code smells are identified through code review, static analysis tools, or team experience. The most common ones include: overly long methods, classes with too many responsibilities (God class), duplicated code, excessive function parameters, long method call chains (train wreck), and poorly descriptive variable or method names. Each smell has an associated refactoring that corrects it: extract method, extract class, remove duplication, introduce parameter object, among others.
Why it matters
Code smells are early signals of code deterioration. Ignoring them does not cause immediate problems, but over time they make code harder to understand, modify, and test. Addressing smells regularly keeps the codebase healthy and prevents the accumulation of technical debt that eventually slows down the development team.
Practical example
A team reviews a notification service and finds a 200-line method that handles sending emails, SMS, and push notifications with multiple nested conditional blocks. The code smell is clear: long method with too many responsibilities. The refactoring involves extracting three specialized classes (EmailSender, SmsSender, PushSender) with a common interface. Each class has fewer than 50 lines, is easy to test independently, and can be modified without affecting the other channels.