Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: Why I Hate Nested If-Else blocks

by dws (Chancellor)
on Jan 04, 2002 at 02:33 UTC ( [id://136125] : note . print w/replies, xml ) Need Help??

in reply to Why I Hate Nested If-Else blocks

Another common way to reduce nesting (and, in some cases, to eliminated nested if-else blocks) is to use guard clauses.

A guard clause prevents complete entry to a subroutine unless a condition is met. It is a special case of an if-else block, and (if you use them) an exception to the "single entry, single exit" rule imposed by structured programming.

A guard clause allows:

if ( ! ref $_[0] ) { return undef; } else { blah($_[0]); }
to be written as
return undef unless ref $_[0]; # guard clause blah($_[0]);
You see guard clauses all the time if you spend any time inside of standard modules like

One of my standard refactorings for deeply nested code written by unrepentant structured programming purists is to reduce nesting by "pulling up" the guard clauses.

Update: I checked Martin Fowler's book Refactoring, and sure enough, he has a refactoring called "Replace Nested Conditional with Guard Clauses." He cites Kent Beck's 1997 book Smalltalk Best Practice Patterns, though Beck was codifying what was already a standard practice in the Smalltalk community.

Replies are listed 'Best First'.
Re: Why I Hate Nested If-Else blocks
by mojotoad (Monsignor) on Jan 04, 2002 at 04:29 UTC
    Iīm glad you mentioned guard clauses, dws. They are particularly appropriate in light of jeffa mentioning Karnough maps.

    Much of the point of guard clauses (and more elaborate if-then-else structures) is to reduce to a known state at any given moment, i.e., normalize your input states.

    Interestingly, in EE, where Karnough maps are drilled into your head during beginning digital design courses, this takes on added importance when you implement your logic using hardware circuits. The logical reductions provided by Karnough maps do not come for free in the hardware world: they result is so called "donīt care" states, areas on the K map that represent theoretically irrelevant input states that under normal circumstances should never be reached.

    In hardware, however, there is no absolute guarantee as to what state the circuit will land in once you flip on the power. Or, at least, thereīs no guarantee in a poorly designed circuit. You have to guard against these unknown initial conditions with some additional circuitry up front that will guarantee a known starting state.

    None of this, naturally, does diddly squat for your TTL project if you dump a coke on it.


    Beware the Santa Clauses!.