> For the complete documentation index, see [llms.txt](https://www.pranaypourkar.co.in/the-programmers-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.pranaypourkar.co.in/the-programmers-guide/java/code-quality-and-analysis/code-smells/types-of-code-smells.md).

# Types of Code Smells

## About

Code smells can be categorized based on the kind of problem they indicate whether it's structural, behavioral, or related to object-oriented misuse. Understanding these categories helps in identifying and addressing them systematically.

Here are the most common types of code smells -

## 1. **Bloaters**

These are code elements that have **grown too large or too complex**, making them hard to understand and maintain.

* **Long Method**: A method that does too much or spans too many lines.
* **Large Class**: A class that tries to handle too many responsibilities.
* **Long Parameter List**: Methods with too many parameters, reducing clarity.
* **Primitive Obsession**: Overuse of primitive types instead of small domain-specific objects.
* **Data Clumps**: Groupings of variables that often appear together but are not encapsulated.

{% hint style="success" %}
*Refactoring*: Extract method, introduce parameter object, replace primitives with objects.
{% endhint %}

## 2. **Object-Oriented Abusers**

These smells arise from **violations of object-oriented principles** such as encapsulation or inheritance.

* **Switch Statements**: Overuse of conditional logic instead of polymorphism.
* **Temporary Field**: Fields that are only sometimes used by an object.
* **Refused Bequest**: Subclass uses only some of the inherited methods or fields.
* **Alternative Classes with Different Interfaces**: Two classes that do similar things but have different method names.

{% hint style="success" %}
*Refactoring*: Replace conditionals with polymorphism, extract subclasses, apply interface standardization.
{% endhint %}

## 3. **Change Preventers**

These smells make code **hard to change or extend** due to tight coupling or scattering.

* **Divergent Change**: One class needs to change for many different reasons.
* **Shotgun Surgery**: A single change requires edits in many different classes.
* **Parallel Inheritance Hierarchies**: Whenever you create a subclass in one hierarchy, you must create a corresponding subclass in another.

{% hint style="success" %}
*Refactoring*: Move methods, collapse hierarchies, use delegation.
{% endhint %}

## 4. **Dispensables**

These are **unnecessary or redundant code elements** that clutter the codebase.

* **Duplicate Code**: Same logic appearing in multiple places.
* **Dead Code**: Code that is never executed or used.
* **Speculative Generality**: Code written for anticipated future use that never materializes.
* **Lazy Class**: Classes that are not doing enough to justify their existence.
* **Comments**: Overuse of comments in place of readable, self-explanatory code.

{% hint style="success" %}
*Refactoring*: Remove, inline, or simplify code; rename methods for clarity.
{% endhint %}

## 5. **Couplers**

These smells indicate **excessive dependencies between classes**, violating the principle of low coupling.

* **Feature Envy**: A method that uses more features of another class than its own.
* **Inappropriate Intimacy**: Classes that are too familiar with each other's internals.
* **Message Chains**: A client asks one object for another and so on — a chain of method calls.
* **Middle Man**: A class that delegates most of its functionality elsewhere.

{% hint style="success" %}
*Refactoring*: Move methods, hide delegate chains, use wrappers or facades.
{% endhint %}

## 6. **Concurrency Smells**

These arise when **multi-threaded code** is poorly structured:

* **Shared Mutable State**: Multiple threads accessing/modifying the same data unsafely.
* **Excessive Locking**: Unnecessary or broad synchronization that harms performance.
* **Deadlocks**: Circular dependencies in locks leading to blocked threads.

{% hint style="success" %}
*Refactoring*: Use immutability, fine-grained locking, thread-safe constructs.
{% endhint %}

## 7. **Architecture Smells**

These occur at a **higher level** than individual classes or methods.

* **Cyclic Dependencies**: Modules or packages depend on each other circularly.
* **God Object / God Class**: A class that knows too much or does too much.
* **Unstable Dependencies**: High-level modules depend on low-level ones that change frequently.

{% hint style="success" %}
*Refactoring*: Break cycles, extract services, enforce architectural boundaries.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://www.pranaypourkar.co.in/the-programmers-guide/java/code-quality-and-analysis/code-smells/types-of-code-smells.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.