Guard clauses flatten the rest
The most common nested shape is a series of refusals, each with an else:
if active:
if no_fines:
if available:
return "yes"
Four levels deep, and the success case — the thing the function is for — is buried furthest from the left margin, while every failure sits in an else far from the condition that caused it.
Inverted, each failure handles itself and leaves:
if not active: return "membership inactive"
if fines > 0: return "unpaid fines"
if not available: return "book is out"
return "yes"
Now every rule sits beside its own message, the happy path is the last line at zero indentation, and adding a rule is one line rather than another level. The page runs both over the same four cases and prints them side by side, because the point is that the behaviour is identical and only the shape changed.
elif is not nesting
if n > 100: ... elif n > 50: ... else: ...
An elif chain is one decision with several outcomes, all at the same indentation. Reaching for a nested if where an elif would do is how a flat choice becomes a staircase.
The rule of thumb
Two levels is normal. Three is worth a second look. Four almost always means either a set of guard clauses waiting to be inverted, or a block that wants to be its own function.
When nesting is genuinely right
Guard clauses suit functions, because return is what makes them possible. Inside a loop or a block where you cannot return, the staircase is sometimes unavoidable - though continue plays the same role in a loop that return plays in a function, and is under-used for it.
Nesting is also right when the conditions are genuinely dependent: when the second question only makes sense if the first was true. if user is not None: followed by if user.active: is not a staircase to flatten, it is two questions where the second would raise without the first.
Combining with and or
Two shallow conditions can often become one:
if user.active and not user.fines:
This is clearer than nesting when the combination is what you mean, and worse than nesting when you need different responses to each failure - as soon as you want to tell the user *which* rule stopped them, the conditions have to be separate again.
Both and and or short-circuit, which is what makes if user is not None and user.active safe: the second half is never evaluated when the first is false. That ordering is load-bearing, and swapping the halves turns a working check into an AttributeError.
Depth as a design signal
Three levels of nested conditions inside a loop inside a function is usually not a formatting problem, it is a sign that the function is making several different decisions and would be clearer as two or three named functions. The indentation is doing you a favour by making that visible.
The same logic, four ways
One rule set written four ways, so the difference is shape rather than behaviour:
def price(age, member):
if age < 18:
if member:
return 0
else:
return 5
else:
if member:
return 8
else:
return 12
def price_flat(age, member):
if age < 18 and member:
return 0
if age < 18:
return 5
if member:
return 8
return 12
for age, member in [(10, True), (10, False), (30, True), (30, False)]:
print(age, member, price(age, member), price_flat(age, member))
10 True 0 0
10 False 5 5
30 True 8 8
30 False 12 12
Both are correct, and which reads better is genuinely arguable here. The nested version makes the two-by-two structure visible: two ages, two membership states, four outcomes. The flat version reads as a list of rules in priority order, which is how a price list is usually written down.
The point of running both is that flattening is not automatically an improvement. It is an improvement when the nesting was accidental — when the inner if was the whole body of the outer one, or when the branches were refusals. When the nesting reflects a genuine grid of cases, keeping it can be the honest thing to do.
Conditions that depend on each other
There is one case where flattening with and is not merely a style choice but actually required, and it comes from short-circuiting.
user = None
if user is not None and user.active:
print("never reached, and never raises")
print("fine")
fine
and stops as soon as the left side is false, so user.active is never evaluated. Reverse the two halves and the same line raises AttributeError — the check that was supposed to protect the access happens after it.
This is why nesting if user is not None: around if user.active: and flattening it to a single and are equivalent: both express "only ask the second question if the first was true". What is *not* equivalent is writing them in the other order, or joining them with &, which evaluates both sides unconditionally.
The general shape is worth recognising. Any time one condition establishes that the next one is safe to ask — not None, non-empty, key present, index in range — the order is load-bearing and cannot be rearranged for readability.
Where the nesting actually came from
Deep conditionals are rarely written that way. They accumulate, and the history is usually visible in the code.
A function starts with one check. A bug report arrives and someone adds a second condition inside the first, because that is the smallest possible change and it does not disturb what is already there. Six months and four reports later there are five levels, each added by someone being careful.
That is worth knowing because it tells you what the fix is. The problem is not that a particular developer wrote bad code; it is that adding a nested if is always the locally cheapest change, and nothing pushes back. The remedy is to treat depth as a review signal — when a change would add a fourth level, that is the moment to restructure, not later.
The restructuring is nearly always one of three moves. Invert the refusals into guard clauses. Combine conditions that were only ever both-required. Or extract the inner block into a function with a name, which resets the indentation and gives the logic a label at the same time.
Writing the condition so it reads
Flattening helps only if the resulting condition is readable, and a flattened condition can easily be worse than the nesting it replaced. Three habits keep it honest.
Avoid stacked negatives. if not (not active or banned) is correct and nobody can evaluate it at a glance. De Morgan's rules let you push the negation inwards — not (A or B) is not A and not B, and not (A and B) is not A or not B — and the version with fewer negations is almost always the one to keep. Better still, name the positive: if is_eligible:.
Name the compound. When a condition needs three clauses, assigning it to a well-named variable on the line before turns the if into a sentence. can_borrow = user.active and not user.fines and book.available followed by if can_borrow: reads as intent, and the name explains what the combination *means* rather than only what it checks.
Keep comparisons in a natural order. if 0 <= n < 100 reads as a range and chains correctly in Python, where most languages would need two comparisons and an and. Writing if n >= 0 and n < 100 says the same thing with more to parse.
The underlying test is whether a reader can say what the condition means without evaluating it. A staircase of simple conditions is sometimes easier to read than one flat condition that requires bookkeeping, and when that is true, the staircase is the right answer.
Every branch is a case to test
Nesting has a cost that is invisible while writing and obvious while testing: the number of paths multiplies.
Two nested conditions give four combinations. Three give eight. A function with four levels has sixteen paths through it, and the tests either cover all of them or leave some untried — and the ones left untried are, by construction, the unusual combinations where the bugs are.
Guard clauses do not remove the combinations, but they change what a test has to do. Each guard is a single condition with a single outcome, testable on its own by passing one bad value and checking one message. The final line is the case where everything passed. The tests read as a list matching the guards, and a new rule adds one test rather than doubling the table.
This is the practical argument for flattening, and it is stronger than the aesthetic one. A shape that makes each rule independently testable is a shape where a change to one rule cannot silently affect another — which is exactly the property a staircase does not have, because every inner branch sits inside the assumptions of every outer one.
The third remedy, after combining and inverting, is to give the inner block a name. It is the one people reach for last and it is often the best.
When a conditional is deep because the innermost part is doing real work, the depth is telling you that two jobs are in one function: deciding, and doing. Moving the inner block into its own function leaves an outer function that reads as a sequence of decisions ending in a call, and an inner one that starts at the left margin with its own name explaining what it is for.
The mechanical benefit is the indentation reset. The real benefit is the name. A block that was three levels deep and unlabelled becomes something with a title, which forces you to say what it does — and occasionally reveals that you cannot, because it was doing two things.
This is also the move that makes the guard-clause style available where it was not. Guards need return, and a block buried in a loop inside a function has nowhere to return to; extract it, and the guards become possible inside the new function.
Questions people ask
Is there a limit to how deep nesting can go? Python allows about twenty levels before the parser complains, which is far past the point where anyone can read it.
Does flattening change performance? Not meaningfully. Both forms evaluate the same conditions in the same order.
Should I use elif or a nested if? elif when the conditions are alternatives to each other, nesting when the second question only makes sense given the first.
What about match? When the branching is on the shape or value of one object, match often expresses it more directly than either nesting or an elif chain.
Can guard clauses be used outside a function? continue plays the same role inside a loop, and it is under-used for exactly this.
Is an early return bad practice? The single-exit rule comes from languages with manual cleanup. In Python, early returns make guard clauses possible and are standard style.
How do I handle "at least one of these must be true"? or, or any() over a list of conditions when there are more than two or three.
Does an early return make a function harder to debug? No. A breakpoint on each guard is as easy as one at the top, and the stack is shallower when it fires.
What about conditions that are expensive to evaluate? Order them cheapest first. Short-circuiting means an expensive check is skipped whenever a cheaper one has already decided the answer.
Is a dictionary lookup ever a replacement for the whole thing? Yes, when every branch is comparing one value against a constant. That is the dispatch table from the dictionary methods page.
Recap in one screen
- If the inner
if is the entire body of the outer one, the two conditions are an and. - Refusals belong at the top as guard clauses, so the main path stays at the left margin and each rule sits beside its own message.
- Genuine nesting is when the second question only makes sense given the first — and short-circuiting makes the order load-bearing.
elif is one decision with several outcomes; reaching for nesting there turns a flat choice into a staircase.- Three levels is a review signal: combine, invert, or extract a function.