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 ---




>Hi all
>
>I would argue that the introduction of those evil commands - LOOP and EXIT - was just for lazy programmers who can't be bothered to restructure (indent etc.) their control loops when they suddenly discover another condition, or change necesaary to the loops. They are unnecessary and should never have been introduced. Personally I have managed NEVER to use them. When you have to debug someone else's labrythine, monolithic code, with 20 yard long do while loops, and short-circuiting loops and exits liberally scattered in the code, just to complicate it even further, like I have, then you'd get to hate them.
>
>I'd challenge anyone to present code where they're necessary.
>
>While I'm at it, don't get me started on multiple RETURN statements in a function ...
>
>:-)
>
>Terry