Using Boolean variables as flags introduces accidental implementation complexity and pollutes the code with Ifs.
TL;DR: Avoid Boolean variables, they lead to conditional logic and force you to write Ifs. Create polymorphic states instead.
Problems
- Extensibility
- Comparison in some languages
- Missed polymorphism
- Limited semantics
- Primitive obsession
Solutions
- If Boolean maps to a real-world entity is safe.
- Model Booleans as a State to favor Extensibility following the Open/Closed Principle.
- Create intention-revealing objects
- Replace Booleans with polymorphism
Refactorings ⚙️
https://maximilianocontieri.com/refactoring-014-remove-if
Examples
Context
Boolean variables tempt you to oversimplify complex domains.
When you use a Boolean, you force two states where many might exist.
This creates coupling because you hardcode behavior based on true/false checks scattered throughout your code.
Booleans also hide intent. A variable named flag tells you nothing about what it represents in the real world.
Even descriptive names like isActive or hasPermission leak implementation details instead of revealing domain concepts.
The problems multiply when you need a third state. You cannot extend a Boolean without breaking existing code.
You end up with multiple Boolean combinations that create implicit states, making your code fragile and hard to understand.
Real-world entities rarely have just two states.
A traffic light isn't "on" or "off"—it's red, yellow, or green. An order isn't just "paid" or "unpaid"—it might be pending, processed, shipped, or delivered.
Sample Code
Wrong
<?
function processBatch(
bool $useLogin,
bool $deleteEntries,
bool $beforeToday) {
// ...
}
Right
<?
function processBatch(
LoginStrategy $login,
DeletionPolicy $deletionPolicy,
Date $cutoffDate) {
// ...
}
Detection
[X] Manual
Automatic detection can warn for B usage, but this can yield false positives.
You can search for boolean attributes in classes, Boolean parameters in methods, and conditional statements that check Boolean values.
Look for variables with "is", "has", "can", or "flag" in their names.
Watch for multiple Boolean combinations that represent different states.
Exceptions
- Real-world true/false rules
- Some languages have issues with Boolean comparators.
In these coupled with accidental complexity languages, Booleans are a common error source.
Level
[x ] Intermediate
Why the Bijection Is Important ️
Your code should always mirror reality.
When you use a Boolean to represent an employee's status, you break the bijection between your software and the MAPPER.
Real employees don't have a true/false state. They have concrete statuses like "on vacation" or "working remotely."
This broken mapping creates a gap between how domain experts think and how your code works. Business people talk about "vacation status" or "remote work," not about "is_on_vacation equals true."
When you model with Booleans, you force translation between business language and code, increasing cognitive load and error potential.
The bijection violation compounds when requirements change. Adding a new employee status means modifying all the boolean logic scattered across your codebase.
With proper domain modeling, you simply add a new status class. The broken mapping makes your code rigid where reality is flexible.
AI Generation
AI code generators frequently create Boolean flags because they optimize for brevity and simplicity.
They often suggest is_active or has_permission flags when generating boilerplate code.
You need to explicitly request domain modeling to avoid this pattern.
AI Detection
AI tools can detect Boolean variables with medium accuracy when you provide context.
You need to specify that you want domain-driven design and state pattern usage.
Simple prompts might not catch the smell without explicit instructions to avoid Booleans.
Try Them!
Remember: AI Assistants make lots of mistakes
Suggested Prompt: correct=Replace Boolean variables with polymorphism
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.
Relations ❤️
https://maximilianocontieri.com/code-smell-51-double-negatives
https://maximilianocontieri.com/code-smell-62-flag-variables
https://maximilianocontieri.com/code-smell-104-assert-true
https://maximilianocontieri.com/code-smell-24-boolean-coercions
https://maximilianocontieri.com/code-smell-101-comparison-against-booleans
https://maximilianocontieri.com/code-smell-122-primitive-obsession
https://maximilianocontieri.com/code-smell-199-gratuitous-booleans
https://maximilianocontieri.com/code-smell-270-boolean-apis
https://martinfowler.com/bliki/FlagArgument.html
Also Known as
Credits
Photo by Phil Hearing on Unsplash
This article is part of the CodeSmell Series.
https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code