Code Smells: Indicators of Deeper Problems, Not Flaws
A code smell is a surface-level hint, like a long method, that suggests a deeper design problem. It's an indicator, not a definitive flaw. The footgun is blindly "fixing" every smell; a smell is a reason to investigate, not an automatic command to refactor.
The mental model
A code smell is a surface indication that usually corresponds to a deeper problem in the system. It's not the problem itself, but a symptom that's quick to spot, or "sniffable." Think of it as a smoke alarm: the alarm isn't the fire, but it warns you to look for one. The term was coined by Kent Beck and popularized by Martin Fowler.
How it works
A developer notices a characteristic in the code that is often associated with poor design, such as a very long function or a class that only holds data. This smell doesn't automatically mean the code is bad, but it serves as a trigger for a deeper look. The developer then investigates to see if an underlying issue, like low cohesion or high coupling, exists. If a problem is confirmed, the smell has successfully guided the developer toward a valuable refactoring opportunity.
When to use it
Use code smells as a guide for continuous improvement and refactoring. They are excellent teaching tools; junior developers can easily learn to spot them, even if they don't yet know how to fix the underlying issue. Teams can adopt a "smell of the week" to focus their learning and collectively improve code quality, making architectural improvement a concrete, shared activity.
When not to use it
Do not treat code smells as a strict, dogmatic rulebook. The biggest mistake is refactoring code just because it exhibits a smell, without confirming a real problem exists. Some long methods are fine. A smell is a heuristic, a rule of thumb, not a law. Always investigate the "why" before changing the code. Blindly "fixing" smells can introduce new bugs or complexity for no real benefit.
One canonical example
A "Data Class" is a class that has fields, getters, and setters, but no other behavior or methods. This is a smell because object-oriented design suggests that data and the behavior that operates on it should be bundled together. When you see a Data Class, ask: "What behavior belongs in this class?" The refactoring process then involves moving methods from other parts of the code that operate on this class's data into the class itself. This turns an anemic object into a rich, useful one.
Interview question
What is the recommended first step when a developer identifies a code smell?
- a.Investigate to determine if an underlying design problem is present.Correct
- b.Refactor the code to remove the characteristic causing the smell.
- c.Document the smell in the codebase for future consideration.
- d.Consult with a team lead or senior developer for guidance on how to proceed.
Why? this is the answer
The card emphasizes that a code smell is an indicator, not a definitive flaw, and serves as a 'trigger for a deeper look.' The 'biggest mistake' is refactoring without confirming a real problem, making investigation the crucial first step. While documentation or consultation might follow, the primary action is to investigate the 'why' before making changes.
Just read this? Test yourself on what you have been reading.
Read the original → martinfowler.com
- #refactoring
- #code quality
- #technical debt
- #agile
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles