DEV Community

loading...
Cover image for Code Smell 07 - Boolean Variables

Code Smell 07 - Boolean Variables

Maxi Contieri
Learn something new every day. - I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Updated on ・2 min read

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) {
    //...
}
Enter fullscreen mode Exit fullscreen mode

Right

<?

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

Detection

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

Relations

Some languages have issues with boolean comparators.

Alt Text

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

Also Known as

  • Flag Abuser

Tags

  • Declarative

  • Primitive

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.

Last update: 2021/06/08

Discussion (0)