How To Make Your Code Faster with Boolean Algebra

Why Every Programmer Should Learn Boolean Algebra
It makes your code faster. Not in a theoretical or subtle way, in a "this exact line decides how much work your server does" way.
A single Boolean expression can be the difference between code that returns in milliseconds and code that takes seconds. Look at these two conditions, they have the same functionality but one much faster.
if (expensiveCheck() && isLoggedIn())if (isLoggedIn() && expensiveCheck())Boolean Algebra Isn't Just for Hardware
Most people stop thinking about Boolean algebra the day the digital logic final ends. That's a mistake, because it never actually left your code. Every if, every while, every SQL WHERE clause, every search filter your product runs is a Boolean expression evaluating true or false against real data.
The compiler doesn't know your intent, it only knows the expression you wrote. Two logically equivalent expressions can compile to wildly different amounts of runtime work, and the rules for which is which are exactly the rules of Boolean algebra: short-circuit evaluation, De Morgan's laws, distribution, factoring. You already used one of them in the last section without naming it.
The rest of this post is three of those rules, applied to code you'd actually write.
Eliminate Unnecessary Work
Short-circuit evaluation means && stops at the first false, and || stops at the first true. Whatever comes after that point never executes. Since you would rather short circuit from the less expensive function, the order matters.
if (expensiveRegex(text) && isValidUser)Try it: order these from cheapest to most expensive
Use the arrows to reorder. These four checks are meant to be chained with && , and any one of them could be the one that fails. The cost numbers are illustrative, not a benchmark, chosen to be roughly the right order of magnitude relative to each other.
- 1API callcost ~200
- 2Database querycost ~80
- 3Boolean flagcost ~1
- 4Regexcost ~15
Simplify Your Conditions
The second rule isn't about order, it's about redundant structure. Boolean algebra lets you factor a condition the same way you'd factor an equation, and the factored version usually costs less to evaluate and is easier for the next person to read.
if (
(isAdmin && canEdit) ||
(isAdmin && canDelete)
)Order Matters at Scale
Principle 1 showed the mechanism. Here's why it matters once you multiply it by real traffic. Say a permission check costs meaningfully more than a login check, and a request comes in from a user who isn't logged in.
if (
expensivePermissionCheck() &&
isLoggedIn()
)if (
isLoggedIn() &&
expensivePermissionCheck()
)In the bad order, expensivePermissionCheck() runs first, unconditionally, on every single request. In the good order, it only runs after isLoggedIn() already returned true. At 10% logged in, that's 90,000 calls to an expensive function that never needed to happen.
Real Consequences
Database queries
WHERE indexed_col = ? AND slow_col LIKE ? versus the same clauses reversed can be the difference between a query that hits an index and one that scans every row before it even gets to the cheap comparison. Query planners are smart, but they're not always smart enough to reorder around an expensive function call.
Search
Cheap filters (category, price range, in-stock) should run before expensive ones (semantic similarity, fuzzy matching). Narrow the candidate set with boolean logic first, then spend the expensive computation only on what's left.
Game development
Axis-aligned bounding box checks are nearly free, compared to full physics collision resolution which can be expensive. Every collision system checks the cheap box first and only runs the expensive math for objects that were already close enough to plausibly collide. These are the kinds of optimizations which can give huge returns in performance from something as simple as changing the order of an if statement or prioritizing less expensive tasks.
Practice Challenge
if (
expensiveValidation(data) &&
userExists &&
hasPermission &&
hasSubscription
)Quick Recap Quiz
Key Takeaways
- Put cheap conditions first, expensive ones last. Short-circuiting does the rest.
- Factor repeated logic instead of duplicating it. Less work, and one source of truth.
- Remove evaluations you don't need before you optimize the ones you do.
- You can even do a simpler check before doing an expensive one to sift unlikely candidates, kind of like what we discussed with the hitboxes earlier.