Code smells

Smells where methods, classes and parameter lists grow too large to read, test or change safely, usually one small addition at a time.

• Long MethodA function that does several jobs in a row and has grown too long to read, name or test as one unit.
• Large ClassA class with too many fields, methods or responsibilities, so every change risks breaking something unrelated inside it.
• Primitive ObsessionDomain concepts like money, emails, IDs or statuses are passed around as raw strings and numbers, so their rules get re-checked everywhere.
• Long Parameter ListA function takes so many parameters that callers mix up their order and every new option changes every call site.
• Data ClumpsThe same group of variables travels together through fields and parameters, signaling a missing object that should own them.

Smells where object-oriented features are missing or misapplied, such as type switches, half-used fields and inheritance that does not fit.

• Switch StatementsThe same switch or if-chain over a type code is repeated across the codebase, so adding one case means editing every copy.
• Temporary FieldA field that is set and meaningful only during one operation or in one special case, and is empty or stale the rest of the time.
• Refused BequestA subclass inherits methods or data it does not want, overriding them to throw or do nothing, so the hierarchy lies about what it can do.
• Alternative Classes with Different InterfacesTwo classes do the same job but expose different method names or signatures, so callers cannot swap one for the other.

Smells where one change forces edits in many places, or one class changes for many unrelated reasons, making every edit slow and risky.

• Divergent ChangeOne class gets edited for many unrelated reasons, so every kind of change lands in the same file and collides with every other kind.
• Shotgun SurgeryOne logical change forces small edits in many classes, so one missed edit ships an inconsistent system.
• Parallel Inheritance HierarchiesEvery new subclass in one hierarchy forces a matching subclass in another, so two trees must always grow in lockstep.

Smells where code, comments or abstractions add nothing, and removing them makes the program shorter and clearer with no loss of behavior.

• CommentsComments that explain what unclear code does are a sign the code should be renamed or restructured so it explains itself.
• Duplicate CodeThe same logic appears in two or more places, so every fix and change must be made several times and the copies drift apart.
• Lazy ClassA class does too little to justify the file, name and indirection it costs; fold it into its caller or delete it.
• Data ClassA class holds fields and accessors but no behavior, while other classes reach in to do the work that belongs to it.
• Dead CodeVariables, parameters, branches, methods or classes that nothing uses still sit in the codebase, costing reading time and misleading readers.
• Speculative GeneralityAbstractions, hooks and parameters built for future needs that never arrived make code harder to read without serving any current use.

Smells where classes depend too much on each other's data or structure, or where delegation is overused, so one change ripples through others.

• Feature EnvyA method reads and computes on another object's data more than its own. Move the logic to where the data lives.
• Inappropriate IntimacyTwo classes reach into each other's private fields and internals. Cut the back-and-forth by moving members or narrowing what each exposes.
• Message ChainsClient code walks a chain like a.getB().getC().getD() to reach what it needs, coupling itself to every link in the path.
• Middle ManA class mostly forwards calls to another object and adds nothing. Let clients talk to the real object or fold the wrapper away.

Smells that do not fit the main groups, currently the gap left when a library class you cannot edit lacks an operation you need.

• Incomplete Library ClassA library type lacks a method you need and you cannot edit it, so helper logic for it is scattered across your code.
• Thin Tool WrapperA tool for an agent or API consumer that passes an upstream operation through raw - one endpoint, one tool, provider-shaped payloads - so every real task becomes a chain of calls over low-signal data.