So, your code runs, doesn’t throw errors, and delivers the expected output. Great! But that doesn’t mean it’s good. In fact, it might still suck.

Writing code that just works is the bare minimum. If it’s hard to read, maintain, or scale, you’re setting yourself (and your team) up for future headaches. Let’s break down some common signs of bad code and how to improve it.


🚩 Signs That Your Code Sucks

1. It’s Hard to Read

Unreadable code is a nightmare to debug and maintain. If another developer (or future you) can’t quickly understand what your code does, it needs work.

❌ Bad Example:

function x(a, b) {
    if (b > 0) {
        return a + b;
    } else {
        return a - b;
    }
}

What’s x? What do a and b represent? It’s cryptic and confusing.

✅ Better:

function calculateTotal(price, tax) {
    return tax > 0 ? price + tax : price - tax;
}

Now it’s clear what the function does and what each parameter represents.


2. It’s Repetitive (Violates DRY Principle)

Repeating the same logic in multiple places makes your code harder to update and maintain.

❌ Bad Example:

def calculate_area_circle(radius):
    return 3.14159 * radius * radius

def calculate_area_square(side):
    return side * side

def calculate_area_rectangle(length, width):
    return length * width

✅ Better:

def calculate_area(shape, *args):
    formulas = {
        "circle": lambda r: 3.14159 * r ** 2,
        "square": lambda s: s ** 2,
        "rectangle": lambda l, w: l * w
    }
    return formulas.get(shape, lambda: None)(*args)

Now, adding a new shape requires only modifying one dictionary instead of creating a new function.


3. It’s Not Scalable

Hardcoded logic might work now, but as requirements grow, your code will become a mess.

❌ Bad Example:

if (userRole.equals("admin")) {
    showAdminDashboard();
} else if (userRole.equals("editor")) {
    showEditorDashboard();
} else if (userRole.equals("viewer")) {
    showViewerDashboard();
}

✅ Better:

Map<String, Runnable> roleActions = Map.of(
    "admin", this::showAdminDashboard,
    "editor", this::showEditorDashboard,
    "viewer", this::showViewerDashboard
);
roleActions.getOrDefault(userRole, this::showDefaultDashboard).run();

Now, adding a new role only requires updating the map.


4. It’s Not Tested

You think your code works. But without tests, how can you be sure?

✅ Always write tests:

def add(a, b):
    return a + b

def test_add():
    assert add(2, 3) == 5
    assert add(-1, 1) == 0
    assert add(0, 0) == 0

Tests ensure future changes don’t introduce unexpected bugs.


5. It’s Inefficient

Your code might be correct but slow due to poor algorithm choices.

❌ Bad Example (O(n²) time complexity):

def find_duplicates(arr):
    duplicates = []
    for i in range(len(arr)):
        for j in range(i+1, len(arr)):
            if arr[i] == arr[j] and arr[i] not in duplicates:
                duplicates.append(arr[i])
    return duplicates

✅ Better (O(n) time complexity):

def find_duplicates(arr):
    seen = set()
    duplicates = set()
    for num in arr:
        if num in seen:
            duplicates.add(num)
        seen.add(num)
    return list(duplicates)

This version is significantly faster for large datasets.


🚀 How to Write Better Code

Follow coding standards – Use PEP8 (Python), ESLint (JavaScript), etc.
Use meaningful names – Make your variables and functions self-explanatory.
Write modular code – Break large functions into smaller, reusable ones.
Avoid magic numbers – Use constants instead of unexplained values.
Refactor regularly – Continuously improve your code instead of just making it work.
Write tests – Automate checks to ensure reliability.


🎯 Conclusion

Your code working isn’t the finish line—it’s the starting point. By improving readability, scalability, efficiency, and testing, you can write code that doesn’t just work but works well.

What’s the worst coding habit you’ve seen (or been guilty of)? Drop it in the comments! 🚀