Code Smells Catalog

Code smells are surface indications of deeper problems. Like symptoms of an illness, they don't tell you exactly what's wrong, but they point you in the right direction. This article provides a comprehensive catalog of code smells with detection techniques, examples, and recommended refactorings.

📋 At a Glance

Aspect	Details
Total Smells Covered	22 core smells
Categories	Bloaters, OO Abusers, Change Preventers, Dispensables, Couplers
Detection Tools	SonarQube, IntelliJ inspections, SpotBugs
Key Insight	Smell = Symptom, not disease
Business Impact	Early smell detection prevents 60% of major refactorings

🎯 What You'll Learn

After reading this article, you will be able to:

Recognize all major code smells at a glance
Understand the root causes behind each smell
Apply appropriate refactorings for each smell
Configure tools for automatic smell detection
Prioritize smells based on impact and fix difficulty
Use smells in code reviews constructively

🔥 Production Story: The Thousand-Line Method

A team inherited a legacy e-commerce system. The checkout method was legendary:

JAVA(13 lines)
Code
Loading syntax highlighter...

The symptoms:

Bug fixes took 2 days minimum (half day just to understand the code)
Every change broke something else
No one could test it properly (integration test took 8 minutes)
New developers avoided touching it

The smells present:

Long Method (1,047 lines)
Feature Envy (reached into 12 different classes)
Data Clumps (same 5 parameters passed everywhere)
Comments (100+ comments explaining "what" instead of "why")
Duplicate Code (discount logic repeated 4 times with variations)

The fix: 3 weeks of systematic refactoring:

Extracted 14 focused methods
Created 6 collaborating services
Introduced Parameter Objects for data clumps
Result: Each method < 20 lines, 90% test coverage, bugs fixed in hours

🧠 Mental Model: Smell Categories

TEXT(36 lines)
Code
Loading syntax highlighter...

🔬 Deep Dive: Complete Smell Catalog

Category 1: Bloaters

Long Method

What: Method that's too long to understand at a glance.

Threshold: > 20 lines (some say 10)

Symptoms:

Multiple levels of abstraction in one method
Comments separating "sections"
Scrolling required to read method
Multiple responsibilities

JAVA(64 lines)
Code
Loading syntax highlighter...

Refactoring: Extract Method, Replace Temp with Query

Large Class (God Class)

What: Class that does too much.

Threshold: > 200-500 lines, > 15 public methods, > 10 fields

Symptoms:

Class name includes "Manager", "Processor", "Handler", "Util"
Many unrelated methods
Multiple groups of methods using different fields
Difficult to name precisely

JAVA(44 lines)
Code
Loading syntax highlighter...

Refactoring: Extract Class, Extract Subclass, Extract Interface

Primitive Obsession

What: Using primitives instead of small objects for domain concepts.

Symptoms:

String for email, phone, currency code
int for quantities, amounts, IDs
Validation logic scattered everywhere

JAVA(43 lines)
Code
Loading syntax highlighter...

Refactoring: Replace Primitive with Object, Introduce Parameter Object

Long Parameter List

What: Method with too many parameters.

Threshold: > 3-4 parameters

Symptoms:

Easy to mix up parameter order
Boolean parameters (what does true mean?)
Many parameters of same type

JAVA(34 lines)
Code
Loading syntax highlighter...

Refactoring: Introduce Parameter Object, Preserve Whole Object

Data Clumps

What: Same group of data appears together in multiple places.

Symptoms:

Same 3+ parameters passed to multiple methods
Same fields in multiple classes
Same local variables declared together

JAVA(31 lines)
Code
Loading syntax highlighter...

Refactoring: Extract Class, Introduce Parameter Object

Category 2: Object-Orientation Abusers

Switch Statements

What: Complex switch/if-else chains, especially on type.

Symptoms:

Switch on type field
Same switch repeated in multiple places
Adding new type requires changes everywhere

JAVA(26 lines)
Code
Loading syntax highlighter...

Refactoring: Replace Conditional with Polymorphism, Replace Type Code with State/Strategy

Temporary Field

What: Field that's only used in certain circumstances.

Symptoms:

Field is null/default most of the time
Complex conditionals check if field is set
Field only populated for specific operations

JAVA(35 lines)
Code
Loading syntax highlighter...

Refactoring: Extract Class, Introduce Null Object

Refused Bequest

What: Subclass doesn't use or want inherited behavior.

Symptoms:

Overriding methods to throw UnsupportedOperationException
Empty overrides
Ignoring inherited fields

JAVA(31 lines)
Code
Loading syntax highlighter...

Refactoring: Replace Inheritance with Delegation, Extract Superclass/Interface

Category 3: Change Preventers

Divergent Change

What: One class changed for multiple different reasons.

Symptoms:

"I have to change this class whenever..."
Different parts of class change for different features
Multiple developers editing same class for different reasons

JAVA(24 lines)
Code
Loading syntax highlighter...

Refactoring: Extract Class (one per reason for change)

Shotgun Surgery

What: Single change requires modifications to many classes.

Symptoms:

Adding a field requires changes in 10 places
Small feature touches many files
Fear of making changes due to ripple effects

JAVA(20 lines)
Code
Loading syntax highlighter...

Refactoring: Move Method, Move Field, Inline Class

Parallel Inheritance Hierarchies

What: Creating a subclass in one hierarchy requires creating subclass in another.

Symptoms:

Every Shape needs a ShapeFactory
Every Employee needs an EmployeeUI
Hierarchies mirror each other

JAVA(30 lines)
Code
Loading syntax highlighter...

Refactoring: Move Method, Collapse Hierarchy

Category 4: Dispensables

Comments (Excessive)

What: Comments that explain what code does instead of why.

Symptoms:

Every line has a comment
Comments repeat what code says
Comments become outdated
Comments apologize for bad code

JAVA(27 lines)
Code
Loading syntax highlighter...

Refactoring: Extract Method, Rename Method, Introduce Assertion

Duplicate Code

What: Same or similar code in multiple places.

Symptoms:

Copy-paste patterns
Bug fixed in one place but not another
Same structure with slight variations

JAVA(36 lines)
Code
Loading syntax highlighter...

Refactoring: Extract Method, Extract Class, Pull Up Method, Form Template Method

Speculative Generality

What: Code written for "future needs" that never come.

Symptoms:

Abstract class with only one subclass
Parameters/options that are never used
Complex configuration for simple needs
"We might need this someday"

JAVA(21 lines)
Code
Loading syntax highlighter...

Refactoring: Collapse Hierarchy, Inline Class, Remove Parameter

Category 5: Couplers

Feature Envy

What: Method uses more features of another class than its own.

Symptoms:

Method calls many getters on another object
Method manipulates another object's data extensively
Logic should probably live in the other class

JAVA(37 lines)
Code
Loading syntax highlighter...

Refactoring: Move Method, Extract Method

Inappropriate Intimacy

What: Classes that know too much about each other's internals.

Symptoms:

Classes access each other's private data (via reflection or package-private)
Bi-directional dependencies
Changes in one class break the other

JAVA(37 lines)
Code
Loading syntax highlighter...

Refactoring: Move Method, Move Field, Change Bidirectional to Unidirectional

Message Chains

What: Long chains of method calls navigating object structure.

Symptoms:

a.getB().getC().getD().doSomething()
Violation of Law of Demeter
Tight coupling to object structure

JAVA(27 lines)
Code
Loading syntax highlighter...

Refactoring: Hide Delegate, Extract Method, Move Method

Middle Man

What: Class that only delegates to another class.

Symptoms:

Most methods just call same method on another object
Class adds no value
Extra indirection without purpose

JAVA(46 lines)
Code
Loading syntax highlighter...

Refactoring: Remove Middle Man, Inline Method

📊 Smell Detection Tools Configuration

SonarQube Rules

YAML(13 lines)
Code
Loading syntax highlighter...

IntelliJ Inspections

TEXT(16 lines)
Code
Loading syntax highlighter...

⚠️ Common Mistakes

Mistake 1: Treating Smells as Absolutes

Problem: Blindly following smell thresholds.

TEXT(4 lines)
Code
Loading syntax highlighter...

Mistake 2: Refactoring Without Tests

Problem: Fixing smells while breaking functionality.

TEXT(3 lines)
Code
Loading syntax highlighter...

Mistake 3: Over-Refactoring

Problem: Creating new smells while fixing old ones.

TEXT(4 lines)
Code
Loading syntax highlighter...

🐛 Debug This: The Mystery of the Failing Refactoring

A developer reports: "I refactored this method to be shorter and now it doesn't work. But I only extracted methods - I didn't change any logic!"

JAVA(54 lines)
Code
Loading syntax highlighter...

Why does the refactored code fail? Find the hidden code smell!

✅ Solution:

The root cause is a Temporary Field smell combined with unsafe parallelization:

Original problem: currentOrder is a temporary field - it's only valid during processOrder()
Refactoring issue: The new code uses parallelStream(), which executes lambdas in different threads
Race condition: By the time some parallel steps run, currentOrder might already be null

The code smells:

Temporary Field: currentOrder is set, used, then cleared - class state is inconsistent
Mutable Shared State: Field is modified during execution
Hidden Coupling: Methods implicitly depend on currentOrder being set

The lesson: Temporary Field smell makes code fragile. When you pass data through fields instead of parameters, you create hidden dependencies that break under refactoring. Always prefer passing data explicitly.

Fix: Pass order as parameter to each method instead of storing in field.

💻 Exercises

Exercise 1: Smell Identification

⭐ Difficulty: Easy | ⏱️ Time: 15 minutes

Task: Identify all smells in this code:

JAVA(33 lines)
Code
Loading syntax highlighter...

Find: Long Parameter List, Long Method, Switch Statements, Temporary Field, Primitive Obsession

✅ Solution:

Smell	Location	Severity
Long Parameter List	6 parameters	High
Long Method	100+ lines implied	High
Switch Statements	type-based switch	Medium
Temporary Field	tempReport, isProcessing	Medium
Primitive Obsession	String type, String format	Low

Exercise 2: Refactoring Practice

⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes

Task: Refactor this code to eliminate Feature Envy:

JAVA(18 lines)
Code
Loading syntax highlighter...

✅ Solution:

JAVA(33 lines)
Code
Loading syntax highlighter...

Exercise 3: Code Smell Catalog

⭐⭐ Difficulty: Medium | ⏱️ Time: 15 minutes

Task: Match each smell with its primary solution:

Smell	Solution
1. Long Method	A. Replace with Strategy/Polymorphism
2. Long Parameter List	B. Extract Class
3. Data Clumps	C. Introduce Parameter Object
4. Switch Statements	D. Extract Method
5. Divergent Change	E. Move Method to appropriate class
6. Feature Envy	F. Create dedicated class for clumped data

✅ Solution:

Smell	Solution
Long Method	D. Extract Method
Long Parameter List	C. Introduce Parameter Object
Data Clumps	F. Create dedicated class for clumped data
Switch Statements	A. Replace with Strategy/Polymorphism
Divergent Change	B. Extract Class
Feature Envy	E. Move Method to appropriate class

Exercise 4: Refactor Data Clumps

⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 20 minutes

Task: Identify and fix the Data Clumps smell:

JAVA(12 lines)
Code
Loading syntax highlighter...

✅ Solution:

JAVA(20 lines)
Code
Loading syntax highlighter...

Exercise 5: Complete Smell Audit

⭐⭐⭐⭐ Difficulty: Hard | ⏱️ Time: 25 minutes

Task: Perform a complete smell audit on this class and refactor:

JAVA(35 lines)
Code
Loading syntax highlighter...

✅ Solution:

Smells found:

Temporary Fields: initialized, conn, lastQuery
Long Parameter List: 7 parameters
Switch Statements: type-based branching
Long Method: 100+ lines implied
Inappropriate Intimacy: Direct DB connection handling
Feature Envy: Email sending mixed with reporting

JAVA(29 lines)
Code
Loading syntax highlighter...

🎤 Senior-Level Interview Questions

Question #1: How do you prioritize which smells to fix?

Strong answer:

I use a risk-based approach:

High priority:
- Smells in hot paths (frequently changed code)
- Smells blocking new features
- Smells causing production bugs
Medium priority:
- Smells in moderately changed code
- Smells slowing down development
Low priority:
- Smells in stable, rarely-touched code
- Cosmetic smells in working code

Formula:

Priority = (Change Frequency × Bug Density × Business Impact)

Question #2: What's the relationship between smells and SOLID?

Strong answer:

Smells are symptoms of SOLID violations:

Smell	Usually Violates
Long Method	SRP
Large Class	SRP
Divergent Change	SRP
Shotgun Surgery	SRP (inverted)
Switch Statements	OCP
Refused Bequest	LSP
Fat Interface smell	ISP
Feature Envy	SRP, encapsulation

Knowing SOLID helps predict what refactoring to apply.

Question #3: When should you NOT fix a code smell?

Strong answer:

Code is being deleted soon - waste of effort
No test coverage - risk of breaking it
Deadline pressure - log it, fix after
Code is stable and working - "ain't broke"
Smell is intentional (trade-off) - document why
Fix creates worse smell - cure worse than disease

📝 Summary & Key Takeaways

Quick Reference Table

Category	Smell	Refactoring
Bloaters	Long Method	Extract Method
Bloaters	Large Class	Extract Class
Bloaters	Primitive Obsession	Value Object
Bloaters	Long Parameter List	Parameter Object
OO Abusers	Switch Statements	Polymorphism
OO Abusers	Refused Bequest	Composition
Change Preventers	Divergent Change	Extract Class
Change Preventers	Shotgun Surgery	Move Method
Dispensables	Duplicate Code	Extract Method
Dispensables	Comments	Self-documenting code
Couplers	Feature Envy	Move Method
Couplers	Message Chains	Hide Delegate

Detection Checklist

🏁 Conclusion

Code smells are your early warning system. They tell you where problems are brewing before they become crises. Learn to recognize them, and you'll catch issues while they're still easy to fix.

Key insight: Smells are symptoms, not diseases. The same smell can have different causes and need different solutions. Use your judgment.

Your next step: Continue to Part 5 (Code Quality Metrics Framework) to learn how to measure code quality objectively.

📅 Review Schedule for This Article

Day	Task	Time
Day 1	Review Code Smells Catalog table	5 min
Day 3	Redo Exercise 1 (Smell Identification)	15 min
Day 7	Answer interview questions without looking	10 min
Day 14	Redo Debug This (Temporary Field paradox)	10 min
Day 30	Audit one class in your project for code smells	15 min

Next in series: [Part 5: Code Quality Metrics Framework]

📋 At a Glance

🎯 What You'll Learn

🔥 Production Story: The Thousand-Line Method

🧠 Mental Model: Smell Categories

🔬 Deep Dive: Complete Smell Catalog

Category 1: Bloaters

Long Method

Large Class (God Class)

Primitive Obsession

Long Parameter List

Data Clumps

Category 2: Object-Orientation Abusers

Switch Statements

Temporary Field

Refused Bequest

Category 3: Change Preventers

Divergent Change

Shotgun Surgery

Parallel Inheritance Hierarchies

Category 4: Dispensables

Comments (Excessive)

Duplicate Code

Speculative Generality

Category 5: Couplers

Feature Envy

Inappropriate Intimacy

Message Chains

Middle Man

📊 Smell Detection Tools Configuration

SonarQube Rules

IntelliJ Inspections

⚠️ Common Mistakes

Mistake 1: Treating Smells as Absolutes

Mistake 2: Refactoring Without Tests

Mistake 3: Over-Refactoring

🐛 Debug This: The Mystery of the Failing Refactoring

💻 Exercises

Exercise 1: Smell Identification

Exercise 2: Refactoring Practice

Exercise 3: Code Smell Catalog

Exercise 4: Refactor Data Clumps

Exercise 5: Complete Smell Audit

🎤 Senior-Level Interview Questions

Question #1: How do you prioritize which smells to fix?

Question #2: What's the relationship between smells and SOLID?

Question #3: When should you NOT fix a code smell?

📝 Summary & Key Takeaways

Quick Reference Table

Detection Checklist

🏁 Conclusion

📅 Review Schedule for This Article

Tags: