25 Common Code Smells and Their Refactoring Solutions

Good code should be readable, maintainable, and extensible, while bad code exhibits recognizable "code smells" that degrade quality. This article enumerates 25 common smells and shows how to refactor them, primarily using Java examples.

1. Duplicated Code

When identical code appears in multiple locations, maintenance becomes error‑prone. The recommended fix is to extract the common part into a separate method or class.

class A {
    public void method1() {
        doSomething1;
        doSomething2;
        doSomething3;
    }
    public void method2() {
        doSomething1;
        doSomething2;
        doSomething4;
    }
}

After extraction:

class A {
    public void method1() {
        commonMethod();
        doSomething3;
    }
    public void method2() {
        commonMethod();
        doSomething4;
    }
    public void commonMethod() {
        doSomething1;
        doSomething2;
    }
}

2. Long Method

Methods that span many lines are hard to understand. Split them into smaller, well‑named methods using the Extract Method technique.

public void printOwing() {
    // print banner
    System.out.println("****************");
    // calculate total
    double total = getTotalAmount();
    // print details
    System.out.println("name:" + name);
    System.out.println("amount:" + total);
}

3. Large Class

A class that does too many things violates the Single‑Responsibility Principle. Move related responsibilities to separate classes.

class Order { ... }
class Goods { ... }
class Points { ... }

4. Long Parameter List

Group related parameters into a DTO to simplify method signatures.

public void getUserInfo(UserInfoParamDTO dto) { ... }

5. Divergent Change

When a single class must be modified in many places for a new feature, extract the varying parts into separate classes or interfaces (e.g., an Engine interface).

6. Shotgun Surgery

Scattered small changes across many classes indicate the need to centralize the logic, often by moving methods or fields to a new class.

7. Feature Envy

If a method heavily uses another class’s data, move the method to that class.

8. Data Clumps

Frequently co‑occurring fields should be encapsulated in their own value object.

9. Primitive Obsession

Replace groups of primitive fields with a dedicated class to give them meaning.

10. Switch Statements

Replace long if/else or switch chains with polymorphic implementations.

interface IMedalService { void showMedal(); }
class GuardMedalServiceImpl implements IMedalService { ... }
class MedalServicesFactory { ... }

11‑25. Additional Smells

Other smells such as Parallel Inheritance Hierarchies, Lazy Class, Speculative Generality, Temporary Field, Message Chains, Middle Man, Inappropriate Intimacy, Alternative Classes, Incomplete Library Class, Data Class, Refused Bequest, excessive comments, magic numbers, and chaotic layer calls are described with brief explanations and typical refactoring actions (e.g., extracting superclasses, removing middle‑man delegations, encapsulating fields, using enums for constants, and respecting proper layer boundaries).

The article concludes with references to further reading on code quality and software architecture.