Category
Dispensables
Smells where code, comments or abstractions add nothing, and removing them makes the program shorter and clearer with no loss of behavior.
What these smells share
Dispensables are things you can delete. Some were useful once and outlived their purpose. Some were built for a future that never arrived. Some copy logic that already exists elsewhere. All of them cost reading time and maintenance while giving nothing back.
The default treatment is removal or merging. That makes these the safest smells to fix, provided you confirm the code is truly unused or truly duplicated.
Members
- Comments: comments that explain what unclear code does, instead of the code being made clear.
- Duplicate Code: the same logic appears in two or more places and must be changed in each.
- Lazy Class: a class does too little to justify its existence.
- Data Class: a class has fields and accessors but no behavior, while others operate on its data.
- Dead Code: variables, parameters, methods or branches that are never used or never reached.
- Speculative Generality: hooks, parameters and abstract classes added for needs that do not exist.
How to choose within this category
- If the code is never executed, it is Dead Code. Delete it.
- If the code runs but copies other code, it is Duplicate Code. Merge it.
- If an abstraction exists with one implementation and no planned second, it is Speculative Generality. Collapse it.
- If a class exists but does almost nothing, it is Lazy Class. Inline it into its user.
- If a class holds data and others do the work on it, it is Data Class. Move the behavior in, rather than deleting the class.
- If a comment explains what a block does, it signals Comments. Extract and name the block, then delete the comment. Keep comments that explain why.
Typical treatments
- Extract Method, Pull Up Method and Form Template Method for duplication.
- Inline Class and Collapse Hierarchy for lazy classes and speculative abstractions.
- Remove Parameter for unused arguments.
- Move Method and Encapsulate Field for data classes.
For agents
- Verify "unused" with a whole-repository search, including reflection, string-based lookups, public API exports and configuration files. Static analysis misses dynamic calls.
- Do not merge code that only looks alike. Two blocks that change for different reasons are not duplicates.
- A data class at a system boundary (DTO, wire format, database row) is often intentional.
See also
- BloatersSmells where methods, classes and parameter lists grow too large to read, test or change safely, usually one small addition at a time.
- CouplersSmells where classes depend too much on each other's data or structure, or where delegation is overused, so one change ripples through others.
- Inline ClassFold a class that does too little into the class that uses it, moving its fields and methods across and deleting it.
- Extract MethodMove a coherent fragment of a long function into its own well-named function and call it from the original place.
- Collapse HierarchyMerge a subclass into its superclass (or the reverse) when the two have become nearly identical and the split no longer earns its cost.
Original writing and examples. Topic coverage follows Refactoring.Guru, which explains this topic with its own illustrations.