Open a function and let your eyes drift to the right edge of the screen. If the code is leaning over halfway to that edge by line ten, the function is in trouble. Maybe not in a way that breaks tests (deeply nested code can be perfectly correct) but in a way that breaks comprehension. Every level of indentation is another condition the reader has to hold in their head to understand what the innermost line means. Five levels in, the reader is tracking five separate predicates, and the actual work is squeezed against the wall.

This isn't a new observation. The JavaScript community has a name for the worst case: callback hell. It's the staircase of function(err, result) { followed by another, and another, each indented further than the last, until the actual business logic (the reason the code exists) is buried so far inside that you have to scroll right to read it. The escape was promises, then async/await, but the underlying problem isn't specific to callbacks. It shows up wherever code nests deeper than it needs to: nested loops, nested conditions, nested try/catch, nested methods that themselves contain nested blocks. The shape is always the same arrow drifting toward the right margin, and the cost is always the same loss of readability.

Early returns flatten the function

The single most useful technique is the guard clause: when a precondition fails, return (or raise) immediately. Don't wrap the rest of the function in an if and indent everything inside it. Send the bad cases out the front door so the happy path can run flat.

Here's a Python example. The deeply nested version:

def charge_customer(customer, amount):
    if customer is not None:
        if customer.is_active:
            if customer.has_payment_method():
                if amount > 0:
                    return process_charge(customer, amount)
                else:
                    raise ValueError("amount must be positive")
            else:
                raise ValueError("no payment method")
        else:
            raise ValueError("customer is inactive")
    else:
        raise ValueError("customer is required")

The flat version says the same thing:

def charge_customer(customer, amount):
    if customer is None:
        raise ValueError("customer is required")
    if not customer.is_active:
        raise ValueError("customer is inactive")
    if not customer.has_payment_method():
        raise ValueError("no payment method")
    if amount <= 0:
        raise ValueError("amount must be positive")
    return process_charge(customer, amount)

Same logic, same checks, same outcomes...but the second version reads top to bottom like a list of preconditions followed by the actual work. There's no rightward drift, no else clauses to track, and the line that does the real thing is at the same indentation level as the function itself. You can see at a glance what the function does: charge the customer, assuming a handful of conditions are met.

The other thing happening here, quietly, is that the function is now using exceptions for the error cases rather than nesting around them. That's the move from the previous post, applied: when something prevents the function from doing its job, raise; let the caller decide what to do about it. Exceptions are the natural partner of guard clauses. They're how the bad cases leave the function without forcing the good cases to indent around them.

Let collections do the filtering

A lot of nesting hides inside loops. The classic shape is "iterate, check, skip": a for loop with an if that excludes the items you don't care about, and a continue or a nested block for the rest. Whenever you see that pattern, there's almost always a filter you haven't named yet.

Ruby gives you a clean way to skip the nesting entirely. Instead of:

def total_active_balances(accounts)
  total = 0
  accounts.each do |account|
    if account.active?
      if account.balance > 0
        total += account.balance
      end
    end
  end
  total
end

…filter first, then sum the result:

def total_active_balances(accounts)
  accounts
    .select { |a| a.active? && a.balance.positive? }
    .sum(&:balance)
end

The second version has no nesting, no accumulator variable, and reads almost like the spec: from accounts, select the active ones with a positive balance, then sum their balances. The collection operations are the filtering and the aggregation; you don't need a control-flow scaffolding around them.

This leans into functional programming a bit, which is fine in OOP - it's not that you can't use the techniques, it's about the main unit of abstraction. Notice here we are replacing an iterative loop that requires cognitive skill with a declarative description that is much more easily understandable. It was estimated that 80% of IBM's mainframe could have been replaced with filter, map, and reduce. Higher-order functions are powerful. They allow you to focus on the domain, not on managing state in loops.

The same pattern works in Python with comprehensions or generator expressions, and in any modern language with collection pipelines. continue and break are useful when you really need them, but most of the time they're a sign that the loop body is doing two jobs (selecting which items to process AND processing them) and one of those jobs belongs to the collection, not to the loop.

Validate at the edge, trust the middle

Defensive programming gets a bad reputation when it's applied uniformly. Checking every argument in every function for null, type, and range produces a codebase that's mostly assertions and barely any logic. But applied at the edges of a module or a system, it cuts nesting deep inside.

The idea is: validate inputs once, at the boundary where untrusted data enters your code. After that, the rest of the code is allowed to assume the inputs are valid. Inside the trusted region, you don't write if $user !== null around every operation, because the boundary already established that $user is a real user.

Here's a small PHP example. Without an edge check, every method has to defend itself:

class OrderService {
    public function place(?Customer $customer, ?Cart $cart): Order {
        if ($customer !== null) {
            if ($cart !== null) {
                if (!$cart->isEmpty()) {
                    // ... actual logic, three levels deep
                }
            }
        }
    }
}

With validation pushed to the entry point — the controller, the request handler, wherever untrusted data arrives — the service can assume its inputs:

class OrderService {
    public function place(Customer $customer, Cart $cart): Order {
        if ($cart->isEmpty()) {
            throw new EmptyCartException();
        }
        // ... actual logic, no nesting
    }
}

The types now say "non-null"; the one precondition that's specifically the service's job to check is handled with a guard clause; the actual work is flat. The defensive checking still exists, but it lives where it makes sense (at the boundary) instead of being smeared across every function in the system.

Why this matters

Flat code isn't a stylistic preference. It's a property that makes code readable, which makes it changeable, which makes it reliable over time. A reader scanning a function should be able to see, at a glance, what it does: take these inputs, check these conditions, perform this work, return this result. Every level of indentation is a hedge the reader has to keep tracking — "we're inside the case where X is true and Y is false and Z is non-null" — and humans run out of stack space for that quickly. So do agents, by the way.

The techniques are all small. Invert a condition and return early. Replace a nested if/continue with a filter. Push validation to the boundary. Let exceptions carry error paths up the stack instead of nesting around them. None of these are clever. They're just the discipline of letting the function's shape match what the function actually does — preconditions first, work in the middle, result at the end, errors out the side. When the shape matches the meaning, the code stops fighting the reader. That's the goal.