Explain the refactorings "Replace Nested Conditional with Guard Clauses" and "Decompose Conditional". How do they differ, and when do you reach for each?

### The problem being solved Conditional logic is where most complexity hides. Two distinct pathologies show up, and the catalog has a distinct refactoring for each. **Pathology 1 — the arrow / staircase.** Nesting grows to the right: ``` if (employed) { if (!retired) { if (hasContract) { result = normalPay() } else { result = 0 } } else { result = retiredPay() } } else { result = 0 } ``` The reader must hold every open branch on a mental stack, and the interesting line is buried deepest. **Pathology 2 — the cryptic condition.** The shape is flat but the boolean expression and the branch bodies are unreadable: ``` if (date.before(SUMMER_START) || date.after(SUMMER_END)) charge = quantity * winterRate + winterServiceCharge else charge = quantity * summerRate ``` Nothing is nested; you simply cannot tell at a glance what any of it means. ### Replace Nested Conditional with Guard Clauses **Motivation.** Not all branches are equal. Some are *alternatives* (genuinely two normal paths — `if/else` is right for those). Others are *exits*: invalid input, missing precondition, special case that ends the story. A **guard clause** makes the second kind explicit: check it, exit immediately, and never indent the rest. **Mechanics.** Take the outermost condition that leads to an exit. Invert it if needed so the exceptional case is the one tested. Replace it with `if (exceptionalCase) return ...;` at the top of the function. Run tests. Repeat for the next one. When only the main path remains, it sits at zero extra indentation. ``` if (!employed) return 0 if (retired) return retiredPay() if (!hasContract) return 0 return normalPay() ``` **What you gain:** flat structure, each precondition visible in one line, the happy path readable top-to-bottom without tracking state, and easy addition of a new precondition (append a line rather than open a nesting level). **Trade-offs and objections.** The classic objection is "single entry, single exit" — an old structured-programming rule that a function should have exactly one `return`. That rule earned its keep in languages with manual resource cleanup, where every exit path had to free memory. In languages with garbage collection, `finally`, `using`/`defer`, or RAII, forcing one exit produces exactly the nesting the guard clause removes. The modern consensus is that multiple early returns are fine when each is a genuine guard, but you should still avoid returns scattered arbitrarily through the middle of long bodies. A real hazard: if the function must always perform cleanup or logging on the way out, guards must not skip it — use language-level `finally`/`defer`, or extract the guarded core into an inner function that the outer one wraps. ### Decompose Conditional **Motivation.** Apply Extract Function three times — to the condition, to the then-part, and to the else-part — so the conditional reads as intent. ``` if (isSummer(date)) charge = summerCharge(quantity) else charge = winterCharge(quantity) ``` The *why* is now on screen; the *how* is one click away. This also makes the pieces independently testable and reusable, and it frequently reveals duplication (the same predicate computed in five places becomes one named function). **Mechanics.** Extract the condition into a predicate function named for the business meaning (`isSummer`, `isEligible`, `isOverdue`), not the mechanics (`checkDates`). Extract each branch body. Run tests after each extraction. If the branches now differ only in which function they call, a *Consolidate Conditional Expression* or *Replace Conditional with Polymorphism* opportunity may follow. ### How they differ, side by side | | Guard Clauses | Decompose Conditional | |---|---|---| | Attacks | nesting depth / control-flow shape | opaque naming / abstraction level | | Precondition | branches are exits, not equal alternatives | branches are meaningful but unreadable | | Result | flat sequence of early returns | same shape, named predicate + named branches | | Built on | inverting conditions, early return | Extract Function, applied 3× | They compose: flatten with guards first so the structure is visible, then decompose whatever conditions remain complex. Related neighbours in the catalog: **Consolidate Conditional Expression** (several checks with the same outcome merged into one named predicate), **Introduce Special Case / Null Object** (remove a repeated null check entirely), and **Replace Conditional with Polymorphism** (dispatch on type instead of branching). ### Behaviour-preservation pitfalls - **Short-circuit evaluation.** Extracting `a() && b()` into a predicate keeps short-circuiting inside the predicate, but if you eagerly evaluate both into locals first, `b()` now always runs. If `b()` has side effects or can throw, you have changed behaviour. - **Side-effect ordering.** Guards move a check earlier. If the code it jumps over had a side effect (a counter increment, a log line, a lazy initialisation), skipping it is a behaviour change. - **Inverting a condition** with `!` on an expression involving null/undefined or three-valued logic (SQL-style `NULL`) is not always a clean negation. Check the boundary case. - **`else` after `return`.** Once a guard returns, the trailing `else` is dead structure; removing it is part of the refactoring, not an optional style choice.