Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Why I Hate Nested If-Else blocks

by ignatz (Vicar)
on Jan 04, 2002 at 20:49 UTC ( #136301=note: print w/replies, xml ) Need Help??


in reply to Why I Hate Nested If-Else blocks

I must confess that I would much prefer a nested if-else block over something like $ref = $ref unless ref $ref eq 'ARRAY'; I don't see much point in jumping through hoops to avoid nesting. Maybe it's just the novice in me talking.

Yes, there are times when there are much more elegant solutions then nested if-elses, but shouldn't the goal be simplicity over a blanket condemnation? I guess I'm just not seeing the why in "Why I Hate Nested If-Else blocks."

My personal approach is to try to keep any nested blocks deep in the guts of my code. If I see to much of it, that sends out an alarm that I may need to abstract out things a bit more.

Replies are listed 'Best First'.
Re: Re: Why I Hate Nested If-Else blocks
by mstone (Deacon) on Jan 05, 2002 at 04:20 UTC


    > Yes, there are times when there are much more elegant solutions
    > then nested if-elses, but shouldn't the goal be simplicity over
    > a blanket condemnation? I guess I'm just not seeing the why in
    > "Why I Hate Nested If-Else blocks."

    A series of nested conditionals forms a state machine. Every block is its own state, and every test marks a transition from one state to the next:

    if ($a) { if ($b) { &S1; } else { &S2; } } else { if ($c) { &S3; } else { &S4; } }
    is equivalent to:
    +-----(b)->[S1]--+ | | +-----(a)->[test b]--+ |--+ | | | | | +-(not-b)->[S2]--+ | [test a]--| |-->[end] | +-----(c)->[S3]--+ | | | | | +-(not-a)->[test c]--+ |--+ | | +-(not-c)->[S4]--+

    Nested conditionals work well if the machine you're building graphs out to a simply-connected binary tree, like the one above, but they become less desirable as your machine grows more complex.

    Basically, the problem boils down to representing arbitrary data structures with a binary tree. There are some things you just can't do directly, like forming complex connections:

    +-----(b)->[S1]-+ | | +-----(a)->[test b]-+ +---->[S5]-+ | | | | | +-(not-b)->[S2]---+ | [test a]-+ | | +->[end] | | | | | +-----(c)->[S3]-+ | | | | +-->[S6]-+ +-(not-a)->[test c]-+ | | | +-(not-c)->[S4]---+

    So you have to simulate the connections by duplicating nodes:

    +-----(b)->[S1]->[S5]-+ | | +-----(a)->[test b]--+ |--+ | | | | | +-(not-b)->[S2]->[S6]-+ | [test a]--| |-->[end] | +-----(c)->[S3]->[S5]-+ | | | | | +-(not-a)->[test c]--+ |--+ | | +-(not-c)->[S4]->[S6]-+

    Which introduces synchronization problems.

    The more complicated your machine is, the harder you have to twist it around to fit the binary-tree model of nested conditionals. And the more you twist, the harder it is to figure out what the original machine looked like while you're reading the code. In fact, since programmers often evolve code instead of designing it, I'd give strong odds that even the programmer who writes a series of nested conditionals doesn't know what kind of machine he's building, and can't prove that it's a well-formed minimal solution to the problem at hand.

    So it's not that nested conditionals are inherently evil. They're quite useful when applied properly. So are gotos. And like gotos, nested conditionals give programmers a way to disguise sloppy or inconsistent thinking as complex control flow. In other words, they can make code unnecessarily complex while looking perfectly reasonable every step of the way. That's why we should use them carefully and examine them critically, not just accept them blindly.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://136301]
help
Chatterbox?
[atcroft]: stevieb: Apparently it was contagious....
[atcroft]: james28909: Make both hands into fists, place them together (with thumbs concealed), and every knuckle is a month (starting with Jan.) has 31 days, every dip (between knuckles) does not....
[atcroft]: (And Feb. is the odd case, because it is 28, unless it is a year divisible by 4, or if it is divisible by both 100 and 400 (at which point it is 29).)
[james28909]: i know but scroll through your calendar on your computer.
[james28909]: i thiught you were going to say make both hands into a fist and puch yourself in the face
[atcroft]: .oO(Sorry, I probably should have said take two normal hands....)
[atcroft]: james28909: No, unless you are a politician, I wouldn't say that (and even if you are, I still probably wouldn't say that).
[james28909]: i mean how hard can it be? its just subtracting days lol
[atcroft]: james28909: What about October 5, 1582?
[stevieb]: atcroft: "Make both hands into fists..."... is something my Ma taught me in our native lang, but I was to ignorant and young to pay attention. Thanks for that :)

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2017-04-29 04:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I'm a fool:











    Results (531 votes). Check out past polls.