Stop Calling it Bad Code

“This code is bad. We should refactor it.” is something I still hear frequently. “Bad code” has become the common way to refer to any code that's not up to our quality bar. I'm seeing it become a defacto description across the industry, blog posts and in software engineering literature. The summary of the classic book Clean Code starts like this: “Even bad code can function.” But while books and blog posts untangle what they mean by bad code, us, engineers, we rarely do. I’m just as guilty of this behaviour, often just calling code that is not good as bad or sloppy.

But "bad code" is a lazy expression. It’s not specific and means different things to everyone. Take this code sample that is an implementation of FizzBuzz. Is it bad code?

var fizzBuzz = function(n) {
    var outputs = [];
    let fizzDiv = 3;
    let buzzDivision = 5;
    for(let counter=1;counter<=n;counter++) {
        let currentNumber = counter;
        let FIZZ_OUTPUT = "Fizz";
        let buzzOutput = "Buzz";
        if(currentNumber % fizzDiv == 0 
           && currentNumber % buzzDivision == 0) {
            outputs.push(FIZZ_OUTPUT + buzzOutput);
        } else if(currentNumber % fizzDiv == 0) {
            outputs.push(FIZZ_OUTPUT);
        } else if(currentNumber % buzzDivision == 0) {
            outputs.push(buzzOutput);
        } else {
            outputs.push(currentNumber.toString());
        }
    }
    return outputs;
};

Most people will call this bad code, indeed. But what if we banned using the term “bad” and started to be more specific? Then this code could be called inconsistent in naming, overly verbose and hard to maintain. If it was lacking tests, it could also be called untested.

Take this piece of code:

var fizzBuzz = function(n) {
    var o = [];
    for(let c=1;c<=n;c++) {
        o.push(c%15==0?"FizzBuzz":c%3==0?"Fizz":c%5==0?"Buzz":c.toString());
    }
    return o;
};

How could this be described without using generic terms like bad? You could say it’s hard to read, the variable names are non intuitive. But some might also it concise or note the (overly) clever use of the ternary operator. Depending on the environment the code is being written, either of these code samples might be described as following or not following coding conventions.

Beyond just “bad code”

Instead of sticking to a lazy term, put some more effort to describe flaws of the code you see, and improvements you could think of.

• Be specific on the flaws you see, even at the cost of being more verbose. “I find this function too complicated”. “This class has multiple responsibilities”. “The variable name does not describe its purpose clearly”.
• Give a specific suggestion on how to improve the issue, if it not obvious from your description. Thins like “This class has multiple responsibilities. What would you think of breaking it into two parts, one being responsible for serialisation, another for price calculation?” or“I find the name calculate hard to understand. How about calling it getPriceWithoutVAT instead?”
• Talk about the future implications of the code you see, if not changed. Things like “I think the class would probably be hard to reuse, because it has many things hardcoded.” or “I’m pretty sure newcomers would find this code hard to comprehend, as it does not follow conventions used across the codebase.”
• Ask the person writing the code, what they think about your comments. Say thinks like “what do you think about this?” or “do you think this would make sense?”.

From “bad code" to “how to make this better” code

By not using generic and negative terms like “bad”, conversations about code become constructive. Instead of starting with an emotional statement - this code is bad! - you’re now starting with observations and suggestions. Using this approach, people who you give feedback to will not feel threatened and act reflexively defensive, pushing back on your comments. That is what would happen if you started with vague and judging terms, like “bad code”.

Even if it is bad code, take the time and energy to describe what is bad about it. This will help you grow your ability to verbalise of practices that make good code. It will also challenge your own assumptions on what good and bad code means to you, improve your ability to give constructive feedback and it will also help with mentor other developers better, helping them improve their code.

Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 tech newsletter on Substack.