Code smells

Code smells are surface‑level indications in the source code—such as overly long methods, duplicated logic, or large classes—that aren’t bugs per se but suggest deeper design or maintainability problems. They act like warning flags: when you spot a smell (e.g., “God Object,” “Feature Envy,” or “Shotgun Surgery”), it tells you that the code probably violates sound design principles (like SRP or DRY) and may become fragile, hard to understand, or difficult to extend. Refactoring away smells early keeps the codebase cleaner, more modular, and easier to evolve over time.

Types of code smells

Long function

• problem: they are really difficult to understand and you need to set a proper name. Take into account
• solution: Extract it to another function or class[refactor sets.md)

Mysterious name

• problem: any name of variables, functions or classes that don't communicate what it does or how to use it
• solution: * Rename them
• If there is no good name, may be a sign of bad design

duplicated code

• problem: you have the same structure in different parts of the code
• solution: extract to a function / class

long parameter list

• problem: too complicated to handle
• solution: use semantic objects such DTOs

comments

• problem: they are needed when code is not self explanatory
• solution: code needs to be refactored

refused bequest

• problem: implementation of interfaces doesn't need a lot of stuff from parent
• solution: * Create sibling class to push down all the parent code
• Maybe hierarchy is not right

Global data

• problem: it is difficult to identify where the error is having data defined in the global scope.
• solution: use encapsulation into functions / classes

Divergent change

• problem: a change in a context imply different modules
• solution: extract to a function / class

feature envy

• problem: one module communicates more with another than with himself
• solution: move it from context

lazy element

• problem: it was expected to do many things but finally it wasn't needed
• solution: move to another function / class

speculative generality

• problem: code that was added for a possible future feature but was never used
• solution: delete it

temporary fields

• problem: field used for certain cases
• solution: extract to a function / class

message chain

• problem: consecutive objects requests in depth
• solution: delegate, extract or move

middle man

• problem: inverse of message chain
• solution: do not encapsulate too much

insider trading

• problem: some modules communicate a lot with each other
• solution: move or delegate

large class

• problem: it has too many fields, may lead to duplicated code and chaos
• solution: extract to another class

Mutable data

• problem: some data updates may break something in another part of the code
• solution: Places where data is updated need to be monitored and reduced

Paracelsus: the difference between a poison and something benign is the dose