How to Spot and Eliminate Common Code Smells for Cleaner, More Maintainable Code

Martin Fowler: Any fool can write code that a computer can understand. Writing code that a human can understand is what makes a programmer great.

Good code is often described with words like

clean

,

tidy

,

well‑named

,

properly commented

, and

high cohesion, low coupling

. Poor code feels like rotten food – unpleasant to read.

Bad Smell: Long Method

A long method exceeds reasonable length, either horizontally (line width) or vertically (number of lines). Horizontal overflow forces scrolling, reducing readability, especially on small screens. Vertical overflow creates a large function that is hard to understand and modify.

Solutions:

Set a maximum line width in the IDE (e.g., 80 or 120 characters) and format code.

Break long chained expressions, such as Java 8 streams, onto separate lines.

Extract parts of the method into smaller methods using the

Extract Method

refactoring.

Bad Smell: Large Class (God Class)

A God Class violates the Single Responsibility Principle by handling many unrelated responsibilities, making it hard to understand.

Design patterns’ six SOLID principles: SRP, OCP, LSP, ISP, DIP, and the Liskov Substitution Principle.

Indicators of a God Class include:

CPFD – many foreign data references.

WOC – total cyclomatic complexity > 65.

TCC – cohesion ratio < 1/3.

Solutions:

Use

Extract Class

to move related fields into a new class and

Move

related methods.

Use

Extract Subclass

to split responsibilities into subclasses.

Bad Smell: Duplicated Code

Robert C. Martin: Duplication may be the root of all evil in software.

Duplicated code often arises from copy‑paste during rapid development. It leads to missed updates and higher maintenance cost.

Refactoring scenarios:

Scenario 1 – Duplicate logic in two methods of the same class

<code>class A {
    public void method1() {
        logic1
        logic2
        logic3
    }
    public void method2() {
        logic1
        logic2
        logic4
    }
}
</code>

Extract the common part into a new method:

<code>class A {
    public void method1() {
        baseMethod();
        logic3
    }
    public void method2() {
        baseMethod();
        logic4
    }
    public void baseMethod() {
        logic1
        logic2
    }
}
</code>

Scenario 2 – Duplicate logic in sibling subclasses

Move the shared code to a common superclass.

Scenario 3 – Duplicate code in unrelated classes

Extract the duplicated logic into a utility or helper class and use composition.

Bad Smell: Long Parameter List

Excessive parameters reduce readability and make method calls confusing. Adding new features often forces more parameters, increasing caller burden.

Solution: Wrap related parameters into a DTO (Data Transfer Object) and pass the object instead of many arguments.

A DTO is a design pattern for transferring data between software subsystems.

Sometimes a long parameter list is justified to avoid unwanted dependencies, but if the method changes frequently, consider refactoring.

Bad Smell: Shotgun Surgery

When a small change requires edits in many places, it’s easy to miss a spot, leading to bugs.

<code>public class A {
    @Value("${db.mysql.url}")
    private String mysqlDbUrl;
}
public class B {
    @Value("${db.mysql.url}")
    private String mysqlDbUrl;
}
</code>

Solution: Consolidate related fields and behavior using

Move Method

and

Move Field

into a single class or create a new one.

Bad Smell: Speculative Generality

Prematurely adding abstractions for “future” features creates unnecessary complexity and burdens the codebase.

Apply the Simple Design principle: write code for current requirements, then refactor when real future needs emerge.

Bad Smell: Excessive Comments

Common comment smells listed in *Clean Code* include chatter, redundant, misleading, boilerplate, log‑style, useless, explaining variables, location markers, class ownership, and commented‑out code.

Too many or outdated comments obscure the code. Prefer self‑describing names and delete unnecessary comments. If a method needs a comment, it may indicate the method does too many things and should be refactored.

Summary

The article lists several frequent code smells and practical refactoring techniques to help developers write cleaner, more readable code. For deeper study, refer to “Refactoring: Improving the Design of Existing Code” and “Clean Code”.