Maxi Contieri

Posted on Oct 26, 2020 • Edited on Jun 8, 2021

Code Smell 07 - Boolean Variables

#codenewbie #tutorial #beginners

Using boolean variables as flags, exposes accidental implementation and pollutes the code with Ifs.

TL;DR: Don't use boolean variables, they force you to write Ifs. Create polymorphic states instead.

Problems

Extensibility
Comparison in some languages

Solutions

If Boolean maps to a real world entity is safe. Otherwise, model as a State to favor Extensibility. This also follows Open/Closed Principle.

Examples

Flags

Exceptions

Real world true/false rules

Sample Code

Wrong

<?

function processBatch(
    bool $useLogin,
    bool $deleteEntries,
    bool $beforeToday) {
    //...
}

Right

<?

function processBatch(
    LoginStrategy $login,
    DeletionPolicy $deletionPolicy,
    Date $cutoffDate) {
    //...
}

Detection

Automatic detection can warn for boolean usage, but this can yield false positives.

Relations

Some languages have issues with boolean comparators.

In these coupled with accidental complexity languages, booleans are a common error source.

Also Known as

Flag Abuser

More info

Martin Fowler

Conclusion

Take extra care when declaring something boolean. Flags are difficult to maintain and extend.
Learn more about the domain. Try migrating to state design pattern. Use polymorphism instead of ifs/switch/cases.

Credits

Photo by Phil Hearing on Unsplash

These tweets inspired this code smell:

This article is part of the CodeSmell Series.

How to Find the Stinky parts of your Code

Maxi Contieri ・ May 21 '21

#codenewbie #tutorial #codequality #beginners

Last update: 2021/06/08

Top comments (2)

JoelBonetR 🥇 • Aug 4 '22

Using booleans as params is something common and definitely not a code smell, it's more about the context and how it's handled.

const getBreakfast = (isPremium) => {
  return isPremium ? getPremiumBreakfast() : getBasicBreakfast();
}

const getBreakfast = (user) => {
  return user.isPremium ? getPremiumBreakfast() : getBasicBreakfast();
}

None of those is better than the other, it's a matter of how the app is modelled 🤷🏻‍♀️
The alternative is to set which breakfast a user should get as user property which can become quite inefficient and bloated quickly as soon as you get more breakfast menus for different users, have optionals, start serving lunchs, dinners and so on.

Of course this is better than adding multiple params to the getBreakfast function:

const getBreakfast = (user) => {
     let options = { 
       vegan: user.isVegan,
       vegetarian: user.isVegetarian,
       keto: user.isKeto,
    }

    return isPremium ? getPremiumBreakfast({options: options}) : getBasicBreakfast({options: options});

}

Maxi Contieri • Aug 4 '22

is premium has an accidental IF . So it is a code smell

a better solution following open/closed principle would be to delegate on the breakfast using double dispatch. In this way you can have even more than two breakfasts

Ternarys are IFs, so they are also code smell

Code is not better this way, IMHO

DEV Community