DEV Community

Cover image for Why Your Code Works but Still Sucks (And How to Improve It)
Info general Hazedawn
Info general Hazedawn

Posted on

Why Your Code Works but Still Sucks (And How to Improve It)

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;
    }
}
Enter fullscreen mode Exit fullscreen mode

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;
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

✅ 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)
Enter fullscreen mode Exit fullscreen mode

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();
}
Enter fullscreen mode Exit fullscreen mode

✅ Better: 

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

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

✅ 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)
Enter fullscreen mode Exit fullscreen mode

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! 🚀

Top comments (0)