How do early-return guard clauses flatten a deeply nested if statement?

### The shape you are removing A function that validates as it goes grows what reviewers call arrow code: each check adds an indentation level, the real work ends up deepest, and the `else` branches that explain the failures are far below the conditions that caused them. ```python def shipping_cost(order): if order is not None: if order["items"]: if order["country"] == "US": return 5.0 + 0.5 * len(order["items"]) else: return 25.0 else: return 0.0 else: raise ValueError("order required") ``` To read the last line you must hold three open conditions in your head, and to find why an order raises you must scroll to the bottom. ### The rewrite, mechanically For each nested `if` whose `else` is a failure or a trivial early answer: **invert the condition, exit immediately, delete the `else`, dedent the rest.** ```python def shipping_cost(order): if order is None: raise ValueError("order required") if not order["items"]: return 0.0 if order["country"] != "US": return 25.0 return 5.0 + 0.5 * len(order["items"]) ``` Same behaviour, same number of decisions, but the structure now carries meaning. The guards form a readable list of preconditions at the top, each failure sits next to the condition that triggers it, and the final line -- the thing the function is actually for -- is at the outermost indentation. ### Why the flattening is worth something **Invariants accumulate.** Every line below a guard runs in a world where that guard passed. By the last line you know the order exists, has items, and is domestic; none of that has to be re-checked or re-derived. Nesting hides that accumulation behind indentation; guards state it. **Locality of failure.** In the nested version, the reason an empty order returns `0.0` is separated from the test by the whole body. In the guarded version they are adjacent, which is what makes the function reviewable. **Complexity metrics follow.** The number of decisions is unchanged, so cyclomatic complexity is the same; what drops is nesting depth, the metric that correlates with how hard code is to hold in your head. Most linters have a max-nesting rule for exactly this reason. ### Return or raise? Decide by contract. A guard that catches a **broken contract** -- a `None` where the signature promised an object, a negative quantity -- should `raise`, because returning a value would launder a caller bug into a plausible-looking result. A guard that catches a **legitimate boundary case** -- an empty collection, a no-op update -- should `return` the correct answer for that case. Mixing them up produces functions that swallow bugs or that raise on ordinary input. ### The single-exit objection Someone will say a function should have one exit point. That rule comes from languages where every exit path had to repeat manual cleanup, and getting one path wrong leaked a resource. Python does not have that problem: a `with` block runs its `__exit__` no matter which `return` fires, and `try` / `finally` covers the rest. So acquire resources with a context manager and let the guards return freely. One genuine trap remains: **do not put `return`, `break` or `continue` inside a `finally` block** to force an exit. Doing so silently discards any exception that was propagating out of the `try`. Since Python 3.14 (PEP 765) the compiler emits a `SyntaxWarning` for exactly this, and the warning is worth treating as an error. ### Where guards stop helping - **Guards must be cheap and side-effect-free.** A guard that writes, mutates or calls out to a service turns a precondition check into hidden work, and readers stop trusting the block. - **Guards are for exits, not for peers.** If all five outcomes are equal-weight cases rather than early bail-outs, forcing them into guards buries the real decision; a flat chain of alternatives says what it means. - **Too many guards means the function does too much.** Six or seven preconditions is a signal to validate at the boundary once -- parse the input into a validated object -- rather than to re-check the same things in every function that touches it. - **Do not invert a condition into something unreadable.** `if not (a and not b):` is worse than the nesting it replaced; when De Morgan's law makes a guard ugly, keep the positive form. ### What the interviewer is listening for That you can perform the rewrite on the spot, that you name the invariant-accumulation benefit rather than just "it looks nicer", that you choose `raise` versus `return` deliberately, and that you answer the single-exit objection with context managers instead of dogma.