How Clean Code Principles Transform Your Programming Practice

Writing clean code is a universal goal for programmers. *Clean Code* emphasizes first understanding the difference between dirty and clean code, then practicing deliberately to achieve cleanliness.

The metric WTF/min is presented as a sole standard for code quality; Uncle Bob calls bad code a swamp, while a more candid Chinese term is “shit mountain,” highlighting that developers are both victims and perpetrators.

Renowned experts summarize clean code principles:

Bjarne Stroustrup: elegant, efficient, straightforward, low dependency, single purpose.

Grady Booch: simple and direct.

Dave Thomas: readable, maintainable, unit‑tested.

Ron Jeffries: no duplication, single responsibility, expressive.

The author especially values “expressiveness,” which captures the essence of good code: describing functionality simply and precisely.

The Art of Naming

Naming is challenging, especially when English is not the native language, but good names make code intuitive and expressive.

Effective names should be:

Descriptive

A good variable name tells what it is, why it exists, and how to use it; otherwise a comment is needed.

# bad code

def getItem(theList):
    ret = []
    for x in theList:
        if x[0] == 4:
            ret.append(x)
    return ret

# good code

def getFlaggedCell(gameBoard):
    '''Minesweeper: flagged cells'''
    flaggedCells = []
    for cell in gameBoard:
        if cell.IsFlagged():
            flaggedCells.append(cell)
    return flaggedCells

Avoid Misleading Names

Do not promise one thing and deliver another.

Avoid abusing common abbreviations (e.g., using l as a variable or naming a list user).

Meaningful Distinction

Code is for machines and humans; concepts must be distinguishable.

# bad

def copy(a_list, b_list):
    pass

# good

def copy(source, destination):
    pass

Readable Words

If a name cannot be read aloud, discussions become cumbersome.

Search‑Friendly Names

Name length should correspond to its scope.

Avoid Mental Mapping

Using generic names like temp forces readers to translate meaning each time.

Comments

Expressive code should not need comments.

The proper use of comments is to compensate for our failure to express ourselves in code.

Comments serve to fill gaps when code cannot convey intent, but they become harmful if outdated or inaccurate.

# bad
// check if the employee is eligible for full benefit
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))

# good
if employee.isEligibleForFullBenefits()

Good comments include:

Legal information.

Explanation of intent – why something is done.

Warnings.

TODO notes.

Highlighting seemingly unreasonable but important code.

Functions

Single Responsibility

A function should do one thing, evident from its name; if it can be split further, it should be.

Abstraction Level

All statements in a function belong to the same abstraction level. Example:

def pushElephantIntoRefrige():
    openRefrige()
    pushElephant()
    closeRefrige()

This high‑level function hides the details of pushElephant, allowing readers to grasp the overall intent first.

Function Parameters

More parameters increase input combinations, testing effort, and potential bugs. Output parameters are harder to understand than return values, and Boolean flag arguments often violate single‑responsibility, suggesting separate functions instead.

Don’t Repeat Yourself

Functions enable reuse, but when similar code requires many conditional branches, it may indicate that the original function is doing too much and should be refactored.

Testing

Testing, especially unit testing and TDD, is essential for maintaining readable, maintainable, and extensible code. Poor test quality leads to “dirty tests,” which are as harmful as having no tests.

Key testing principles:

Never write production code without a failing unit test.

Write only enough test code to cause a failure.

Write only enough production code to pass the failing test.

FIRST criteria for tests:

Fast – automated and quick.

Independent – no inter‑test dependencies.

Repeatable – passes in any environment.

Self‑validating – returns a boolean result.

Timely – written before the corresponding production code.

Source: https://www.cnblogs.com/xybaby/p/11335829.html