>>>>- Going to the other extreme, can you offer any argument that multiple exit points is always better? If not, on balance I'd have to say single is better. And if it is better (or its arguments are) then it should be promoted as a standard.
>>>
>>>I think this thread has offered agruments favouring multiple exits over singles while most of the counter-arguments were sourced in some nightmare scenario.
>>
>>Don't discount the "nightmare scenarios". Everyone has them. And, real-world experience trumps theoretical discussions.
>
>Is this to suggest that NO 'good program' in the real world has multiple returns? I don't see what you're getting at I guess.

I was mainly trying to point out that you shouldn't discount so-called (by you) "nightmare scenarios". I was fortunate(?) enough to run into an excellent real-world example of why it's bad.

>
>>
>>>But it remains that there is not much EITHER WAY that is (even quite) "decisive", except for personal view points.
>>
>>IYO.
>>
>>>A blanket "always single exit point" just cuts out too many instances where immediate exit is both clearer and faster. So, like much else, it comes down to THINK!!!
>>
>>What I was getting at is, can you imagine any client explicitly specifying multiple exit points? I sure can't. If it's better, why not?
>
>Of course not, but I can see a client saying 'no multiple return points'. While it is the clients's "right" I'd rather see a move to the general abolishment of that as a RULE anywhere. It is clearly far more of a personal thing than empirical goodness and a GOOD programmer can make perfectly good code for anyone else's reading with multiple returns. To me the argument for a RULE for a single exit amount to the same 'strength' as online "all caps message are shouting and hurt my eyes". Spouted by those 'in the know' but totally untrue in fact.

My point is, if there really is nothing to choose between them, you should have just as many people arguing that you should use multiple exit points every time they are applicable. It's a standard technique in mathematics - examine the extreme cases for insight.

>
>>
>>Can you say you've never hit a subtle, hard-to-find bug as a result of multiple exit points? I sure have. Have you ever maintained or enhanced a complex system that indiscriminately uses multiple exit points?
>
>No more so than subtle bugs in single exit programs. In fact probably less, because I did far more debugging in an (mainframe) COBOL/ASM shop where ONE EXIT POINT was the rule.

My point here was, I've encountered subtle bugs *caused by* multiple exit points. Of course, any routine can have subtle bugs.

>>
>>And, while it's a "non-trivial" concept, I wonder if you have any comment on my conclusion of sequential vs. hierarchical logic, which in hindsight is the real underpinning of my dislike for multiple exit points and emphasis on refactoring.
>
>I'm not sure I understand what either is, but I do have trouble understanding how either is much affected by multiple exit points.
>
>>
>>I think Trey Walpole's mention of "encapsulation" is relevant here, as well (as a related subject).
>
>I don't see how multiple exits breaks encapsulation in any way. I suppose a poor programmer could (say by disturbing the environment upon return) but he'd likely do that with a single exit too.
>
>>
>>>
>>>>
>>>>- Final trick question: do you support the use of LOOP in DO...ENDDO?
>>>
>>>Yes, I use LOOP and EXIT frequently in DO WHILE, SCAN, FOR, etc. They wouldn't be in the language if they weren't meant to be used. For the same reason that a "GO TO" (code line) is NOT in the language.
>>>I've never used RETURN TO..., which I guess comes close to a GO TO.
>>
>>C'mon Jim, you can take that "meant to be used" thing too far... or are you still using @...SAY? ;-)
>
>Well they (EXIT, LOOP) **ARE** found in things that define structured programming language components/concepts.
>You're not saying that

FOR x = 1 TO 10
>    ...some code
>    x = 11
>    ...some more code
>NEXT x

>is better than

FOR x = 1 TO 10
>    ...some code
>    EXIT
>    ...some more code
>NEXT x

are you?

No, they're both bad ;-)

llDone = .F.
x = 1

DO WHILE x < 11 AND NOT llDone
  ...some code
  * Set llDone appropriately

  x = x + 1

ENDDO