skip to content

How does short-circuit evaluation influence how you order operands in a compound condition, and what pitfalls arise from relying on it?

level: seniorimportance: should knowfreq 45%

answer

  1. Order changes correctness, cost, and side effects — not just style
  2. Guard before guarded; cheap/decisive before expensive
  3. Never hide a required side effect in a skippable operand
  4. Extract to named booleans/methods for readability
  5. Parenthesize mixed && / || (and bitwise)

basics

~20 s

Because && and || stop early, the order of checks matters: put guards (like null checks) and cheap, likely-decisive tests first so the expensive or unsafe ones run only when needed. The pitfall is hiding required side effects inside an operand that may get skipped.

solid answer

~50 s

Short-circuiting makes operand order semantically and operationally meaningful. Three ordering principles: (1) Safety first — put guards before the operations they protect, e.g. `obj != null && obj.isValid()`, so a failing guard prevents a crash. (2) Cheap before expensive — in `cheapCheck() || expensiveCheck()`, a true cheap check skips the costly one; same for `&&` with a false cheap check. (3) Likely-decisive first — order by probability of settling the result to minimize average work. The main pitfalls: relying on a side effect inside an operand that can be skipped (it silently won't run), making conditions so long they hurt readability, and precedence mistakes when mixing `&&`/`||`. Best practice is to keep operands side-effect-free where possible, extract complex conditions into well-named boolean methods or variables, and parenthesize mixed-operator expressions. This keeps the logic both correct and readable, and avoids order-dependent bugs that surface only when inputs change.

code

java · 20 lines
java
// guard before guarded (null + range)
static boolean firstIsPositive(int[] a) {
    return a != null && a.length > 0 && a[0] > 0;
}

// cheap/decisive first; expensive call only when needed
static boolean authorized(User u) {
    return u.isSuperAdmin()            // cheap field check
        || remotePolicy.allows(u);     // expensive RPC, skipped if super admin
}

// PITFALL: required side effect can be skipped
// if (cacheWarm || warmCache()) { ... }   // warmCache() skipped when cacheWarm

// readability: extract named condition
static boolean canCheckout(Cart c, User u) {
    boolean hasItems = !c.isEmpty();
    boolean eligible = u.isVerified() && u.hasPaymentMethod();
    return hasItems && eligible;
}

go deeper

for a junior

Knows to put the null check before the method call; may not yet think about cost or side-effect ordering.

for a middle

Applies guard-first and cheap-first ordering and recognizes skipped-side-effect bugs.

for a senior

Balances safety, performance, and readability; refactors complex conditions into named booleans/methods and reasons about likely-decisive ordering.

for a principal

Establishes conventions (side-effect-free conditions, extraction, parenthesization), catches order-dependent fragility in review, and weighs micro-optimization against maintainability across the codebase.

## Why order is not just style With short-circuiting (`&&`/`||` skip the right operand once the result is fixed), the **order** of operands affects three things: correctness (whether a guard protects you), performance (whether expensive work runs), and which side effects actually execute. So reordering a condition can change behavior, not just appearance. ## Principle 1 — safety / guard ordering A **guard** is a check that must succeed before a later operation is legal. The canonical case is null-safety: ```java if (user != null && user.hasRole("ADMIN")) { ... } ``` `user != null` guards `user.hasRole(...)`. If `user` is null, `&&` short-circuits and the method is never called — no NullPointerException. Reversing the operands removes the protection. The OR analogue: `if (s == null || s.isBlank())` safely returns early on null without calling `isBlank()`. **Rule: the protecting condition comes before the protected one.** The same applies to range/index guards: `if (i < arr.length && arr[i] > 0)` avoids an `ArrayIndexOutOfBoundsException`. ## Principle 2 — cheap before expensive Evaluation is left-to-right and stops when decided, so put cheap checks first: ```java // && : a false cheap check skips the expensive one if (flagInMemory && hitsRemoteService()) { ... } // || : a true cheap check skips the expensive one if (inLocalCache(k) || queryDatabase(k)) { ... } ``` This reduces average cost, especially on hot paths. ## Principle 3 — likely-decisive first Beyond cost, order by **probability of deciding the outcome**. For `&&`, lead with the check most likely to be **false** (it ends evaluation soonest); for `||`, lead with the one most likely to be **true**. This is a micro-optimization — apply it where profiling shows it matters, not blindly. ## Pitfall 1 — skipped side effects The biggest hazard: putting a **required side effect** in an operand that may be skipped. ```java // BUG: if alreadyLoaded is true, refresh() never runs if (alreadyLoaded || refresh()) { ... } ``` If `refresh()` must always run, this is wrong. Either evaluate it unconditionally first, or use a non-short-circuiting form deliberately. **Best practice: keep operands free of essential side effects.** Conditions should *ask* questions, not *do* work. ## Pitfall 2 — readability Long compound conditions (`a && b && (c || d) && !e`) are hard to read and easy to get wrong. Mitigations: - Extract to **named boolean variables**: `boolean eligible = active && verified;` - Extract to **well-named methods**: `if (isEligible(user) && withinQuota(user))`. - This also makes the *intent* explicit and the code testable. ## Pitfall 3 — precedence when mixing `&&` binds tighter than `||`, and bitwise `& ^ |` bind tighter still. `a || b && c` is `a || (b && c)`. Mixed expressions without parentheses are a classic bug source — **parenthesize for clarity** even when not strictly required. ## Pitfall 4 — order-dependent correctness that hides A condition that 'works' only because a particular operand is currently always non-null/cheap can break when assumptions change. Make guards explicit rather than incidental, so future edits don't silently remove protection. ## Putting it together — a checklist 1. Guard before guarded (null/range checks first). 2. Cheap and likely-decisive before expensive. 3. No essential side effects inside short-circuitable operands. 4. Extract complex conditions to named booleans/methods. 5. Parenthesize mixed `&&`/`||` (and any bitwise) expressions. Following these keeps compound conditions correct under change, fast where it counts, and readable.

  • You see if (cache.isWarm() || cache.warmUp()) — is anything wrong?
    Potentially yes: warmUp() (a side effect) is skipped whenever the cache is already warm. If warming must always happen, this is a bug; if warmUp() is only meant to run when cold, it's fine — the intent should be made explicit.
  • When would you NOT micro-optimize operand order?
    When all operands are cheap and side-effect-free, ordering for performance adds no value; prefer the order that reads most clearly. Optimize only where profiling shows the right operand is genuinely expensive and often skippable.

Ordering checks is like airport security lanes: you scan the boarding pass (cheap, decisive) before the full bag search (expensive), and you check that a passenger exists before searching their pockets (guard before guarded). If a mandatory step is tucked behind an early 'all clear', it gets skipped — that's the side-effect bug.

saying these in an interview costs you the question

  • Putting a method call before its null/range guard
  • Hiding a mandatory side effect in a short-circuitable operand
  • Writing huge compound conditions instead of named booleans/methods
  • Assuming reordering operands is always behavior-preserving
  • Ignoring && > || precedence in mixed conditions

context

resolving links…