Guard clauses

Guard clauses

A guard clause handles a special case at the top of a function and exits at once, so the rest of the body runs knowing the easy exits are already gone. Without them, every precondition becomes another level of indentation, and the real work ends up buried under a stack of if blocks whose braces no one can match.

Method

1. Return early on every precondition failure. Null inputs, empty collections, unauthorized callers, out-of-range values: check each at the top and return or throw immediately. Each guard you add is one nesting level the main logic sheds.
2. Invert the leading if to un-nest the body. Turn if (valid) { ...long... } into if (!valid) return; ...long.... The happy path drops back to the left margin, and the failure case is stated plainly instead of implied by a distant else.
3. Cluster the exits before the main path, not woven through it. All the guards sit together at the top; below them the reader knows the inputs are clean and can follow one straight line. Scattering guards into the middle forces a re-check of assumptions at each step.
4. Drop the else after a return. Once an if block ends in return, its else is redundant: remove it and let the following code run unindented. Chains of return-then-else if flatten into a clean sequence of guards.
5. Keep each guard one concern wide. Split if (!user || !user.active || user.banned) into three guards, each returning its own specific error. A merged condition saves lines but blurs which precondition failed and costs the caller a precise message.
6. Stop flattening when the branches are genuinely balanced. Guards fit lopsided logic: a few exits, then the real work. When two paths carry equal weight and both continue, a plain if/else is honest; forcing early returns there hides half the logic instead of revealing it.

Litmus tests

• Is the function's main work at one or two levels of indentation rather than four?
• Does each guard return a specific reason, or do several failures share one vague exit?
• Reading top to bottom, are all the edge cases handled before the main path begins?

Boundaries

Early returns can skip required cleanup in languages without automatic resource management: use defer, finally, with, or RAII so no exit path leaks a lock or file handle. Where teardown must run on every path, structure the guards around it rather than jumping past it. For the branch-count view of the same code, see cyclomatic-complexity.