>Terry,
>
>My thinking of this is that you're looking at the wrong problem...
>
>I personally use all of those constructs regularly *when and if* they make the code easier to read later on. It's all about readibility and understandibility.
>
>The real problem is code that's too complex and should be broken into separate methods. Good refactoring can take care of this sort of thing. There's nothing heroic about 10 levels deep nested if statements to avoid an early return or an EXIT out of a loop.
>
>What, do you not use a debugger? How does it really help to not have an EXIT or RETURN there? Do you not have to trace your code anyway (all 10 levels down that you're likely to entangle yourself in?), that you can't find a RETURN or EXIT statement?
>
>Not to mention that an early RETURN will save processing cycles - certainly deeply nested code tends to be inefficient for the early exit scenario.
>
>It's not the 'rules' that determine the game, but final execution! What you're after (I think) is readability and ultimiately there are many ways to arrive at that. Trying to force your style onto every one else is outright fascism... <g>
>
>
Rick,

I'll agree, but what I think Terry is talking about is the indescriminate use of these techniques. IOW, rather than being the exception when the problem indicates it, it becomes the rule even if the problem doesn't require it.