Why Clean Code Matters: Master Naming, Classes, Functions & Testing

This article explains why clean code is important for projects, companies, and developers, and how to write clean code.

1. Why keep code clean?

Unclean code grows over time, reducing productivity and leading to issues such as difficult extension, program crashes, overtime, higher hiring costs, and even company failure.

One picture illustrates the impact.

1.1 Start clean from the beginning

Write clean code from the start; never postpone refactoring. The phrase “later equal never” reminds us to act now.

later equal never

2. Naming

Good names improve readability, lower understanding cost, and increase efficiency.

2.1 Bad naming examples

1. Meaningless names:

public interface Animal {
    void abc();
}

2. Inconsistent naming:

public interface StudentRepository extends JpaRepository<AlertAll, String> {
    Student findOneById(@Param("id") String id);
    List<Student> queryAllStudent();
}

Refactored version:

public interface StudentRepository extends JpaRepository<AlertAll, String> {
    Student findOneById(@Param("id") String id);
    List<Student> findAll();
}

3. Redundant naming:

// Get a single object
getXxx();
// Get multiple objects
listXxxx();

3. Classes

Clean classes should follow single responsibility, open‑closed principle, and high cohesion.

3.1 Single responsibility

Classes should be small and have only one reason to change. Example of a class mixing SQL operations and statistics, which should be split.

public abstract class Sql {
    public abstract void insert();
    public abstract void countInsert();
}

After splitting:

public abstract class CountSql {
    public abstract void countInsert();
}

3.2 Open‑closed principle

Software should be closed for modification but open for extension. Example of a monolithic Sql class and its refactored extensible version.

public abstract class Sql {
    public abstract void generate();
}
public class CreateSql extends Sql {
    @Override
    public void generate() { /* ... */ }
}
public class UpdateSql extends Sql {
    @Override
    public void generate() { /* ... */ }
}

3.3 Cohesion

High cohesion means methods share the same data; low cohesion suggests splitting the class.

4. Functions

Clean functions should do one thing, have descriptive names, clean parameters, and clear return values.

4.1 Do one thing

Example of a long method handling validation, compression, and result; refactored into three single‑purpose calls.

public String upload() {
    // validate image (80 lines)
    // compress image (50 lines)
    // return status (5 lines)
    return "0";
}

Refactored:

public String upload() {
    check();
    compress();
    return "0";
}

4.2 Function naming

Names should convey intent, e.g., appendCharacter or insertCharacter instead of vague addCharacter.

4.3 Parameters

Prefer few parameters; encapsulate related data into objects; avoid boolean flags and output parameters.

4.4 Return values

Separate commands from queries; use exceptions instead of error codes.

5. Testing

Testing validates code correctness; test code should also be clean.

5.1 TDD

Test‑Driven Development writes tests before code, ensuring small, incremental steps.

5.2 FIRST principle

Fast, Independent, Repeatable, Self‑validating, Timely.

5.3 Given‑When‑Then pattern

Structure tests for readability.

@Test
public void shouldReturnItemNameInUpperCase() {
    // Given
    Item mockedItem = new Item("it1", "Item 1", "This is item 1", 2000, true);
    when(itemRepository.findById("it1")).thenReturn(mockedItem);
    // When
    String result = itemService.getItemNameUpperCase("it1");
    // Then
    verify(itemRepository, times(1)).findById("it1");
    assertThat(result, is("ITEM 1"));
}

5.4 Automated test generation

Plugins such as Squaretest (paid) and TestMe (free) can generate test skeletons.

6. Conclusion

Writing clean code improves readability, extensibility, development efficiency, and reduces overtime. Developers should read “Clean Code” and adopt these practices early rather than relying on later fixes.