What Is a Code Smell?

Quick answer
A code smell is a surface symptom that hints at a deeper design problem — a warning sign, not a bug by itself.
Classic smells include duplicated code, long functions, and functions with too many parameters.
Smells guide refactoring: when you see one, look for the structural problem behind it.

What is a code smell?

A code smell is a characteristic of code that suggests a deeper problem, the way a smell suggests something is off without telling you exactly what. The term, from Kent Beck and popularized by Martin Fowler’s Refactoring, describes heuristics — duplicated logic, a 200-line function, a class that knows too much — that aren’t wrong in themselves but reliably correlate with code that’s hard to change. A smell is a prompt to investigate, not a verdict.

Common smells

Duplicated code — the same logic copy-pasted, which must be fixed in every copy.
Long function / long method — a function doing too many things, hard to understand and test.
Long parameter list — a function needing too much context to work.
Divergent change — one module you have to edit for many unrelated reasons.
Shotgun surgery — one change forcing edits across many files.
Feature envy — a method that spends more time on another object’s data than its own.

Why smells matter

Smells are the early-warning system for technical debt. Code that smells isn’t necessarily broken today, but it’s harder to change tomorrow — and change is the one certainty in software. Recognizing smells lets you refactor small, while the cost is low, instead of discovering the structural problem during a crisis.

Where this bites vibecoders
AI assistants produce smells at high volume: the same helper regenerated three times in slightly different forms, a handler that grew to 300 lines across prompts, functions taking a dozen parameters because the assistant kept adding what was needed. The habit that helps most is noticing duplication specifically — it’s the most common smell, the easiest to spot, and the highest-value to fix.

Where AI coding assistants get this wrong

Duplicating logic instead of extracting a shared function.
Growing a function by accretion until it does everything.
Generating near-identical blocks with tiny variations, inviting divergence.
Never suggesting refactoring, since “it works” satisfies the immediate ask.

Checklist

Watch for duplication — it’s the most common and costliest smell.
Keep functions small and single-purpose.
Refactor when a change forces edits in many places.
Use smells as prompts to investigate, not rules to blindly enforce.
Add tests before refactoring smell-heavy code.

FAQ

Is a code smell the same as a bug?

No. A bug is incorrect behavior; a smell is a structural hint that the code will be hard to change. Smells often lead to bugs over time, but the code can smell and still work perfectly today.

Should I fix every smell I see?

No. Smells are heuristics, and some “smelly” code is fine in context (a short switch statement, a data-only class). Use them to decide where to look, then judge whether refactoring is worth it given how often the code changes.

What is refactoring?

Refactoring is changing the internal structure of code without changing its behavior — extracting functions, removing duplication, simplifying interfaces. Tests are its safety net: refactor only what you can verify still works.