Sniffing Out Code Smells: A Clean Code Guide

After reading Chapter 1, Clean Code by Robert C. Martin, and Chapter 3, Bad Code Smells by Martin Fowler, I gained valuable insights into writing and maintaining high-quality software. Both chapters emphasize the importance of clean, readable, and maintainable code, while highlighting the consequences of poor practices. Martin’s emphasis on crafting code that communicates clearly and Fowler’s detailed exploration of common “code smells” provide actionable guidance for writing better software. Inspired by these readings, I reflected on practices I want to adopt and avoid to improve my coding habits.

One Thing to StartContinue Doing: Writing Self-Explanatory Code

As Robert Martin states in Clean Code:

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code.”

Fortunately, writing clear, self-explanatory code reduces maintenance costs and avoids unnecessary confusion. Below, I will share some examples of code, one that doesn’t communicate its intent well, and one that does.

function getValue(a) {
    if (a > 50) {
        return a * 2;
    }
    return a / 2;
}

function calculateAdjustedValue(inputValue) {
    const adjustmentThreshold = 50;
    return inputValue > adjustmentThreshold 
        ? inputValue * 2 
        : inputValue / 2;
}

The second example does a far superior job at communicating intent, primarily by using variables that clearly explain the use of the function.

One Thing to Avoid: Hidden Dependencies & Code Duplication

As Martin Fowler notes in Refactoring:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Hidden dependencies and duplicated code make the system fragile and harder to extend or debug. Examples of hidden dependencies and explicit dependences will be shared below.

# Hidden Dependencies
def calculate_total_price(quantity):
    tax_rate = 0.08  # Dependency hidden inside the function
    return quantity * 100 * (1 + tax_rate)


# Explicit Dependencies
def calculate_total_price(quantity, tax_rate):
    return quantity * 100 * (1 + tax_rate)

# Usage:
total = calculate_total_price(quantity=5, tax_rate=0.08)

Now that tax_rate is being passed explicitly, the dependency is clear, making the function reusable and easier to test. Furthermore, an important principle of clean code is DRY (Don’t Repeat Yourself). Consequently, it is crucial to avoid creating duplicate code.

# Duplicated Logic

public int calculateRectangleArea(int width, int height) {
    return width * height;
}

public int calculateSquareArea(int side) {
    return side * side;
}

# Abstracted Logic
public int calculateArea(int length, int width) {
    return length * width;
}

With an example like this, duplicate code seems awfully avoidable, but many more complex examples can quickly arise, and are important to avoid.