Name All Your Booleans

Software developers often praise code that is meaningful enough to be understood without comments. In this post you’ll learn not only why developers want to write meaningful code, but why managers and shareholders want you to as well. I write code like that, and you can too if you adopt the right habits.

One of those habits is naming the content of if statements. Let’s examine some code I found in a popular repository. If you write frontend code, you’ve used or heard of this package.

if (args['--minify'] || args['--optimize']) {
    if (css !== previous.css) {
        let optimizedCss = optimizeCss(css, {
            file: args['--input'] ?? 'input.css',
            minify: args['--minify'] ?? false,
        })
    previous.css = css
    previous.optimizedCss = optimizedCss
    output = optimizedCss
   } else {
        output = previous.optimizedCss
   }
}

What is the problem with this code? The problem is that so much context is needed to cobble the correct meaning of those if statements together in your head. Which conditions do they describe? We can see that the “minify” or “optimize” arguments could be passed to trigger this code block. But what is it doing? Why is it doing it? Those questions are left unanswered. Certainly, “CSS isn’t equal to the previous CSS” describes an inequality, but why is it important? Why are we doing it?

All these questions could easily be answered by naming the booleans. Indeed, they should be named, because they reduce the cost of interpreting the code in your head. For a reader familiar with the codebase, the cost reduction could be from five minutes to twenty seconds. For an unfamiliar reader like myself, the time savings could be in the range of hours or even days.

From a shareholder’s perspective, the company’s developers use time to write new features. Part of that time is spent on comprehending previously written code. A hundred unnamed if statements per day, over the span of several weeks, could cost hours or even days worth of a programmer’s time. Why? Because s/he has to sit there and work out the meaning of the condition on their own. For a shareholder, that’s bad. It means the shareholder generates smaller profits: They pay the developers more and deliver fewer results to clients.

From a developer’s perspective, a lazy approach to development saves you time upfront, and then costs you over and over each time you return to work out the meaning of the unnamed if statement.

Name all your booleans.