Drat. You, too, replied to my incomplete post rather than the complete one. That said, I'll still address your points:

Debugging from the bottom - when I debug I start there. I can see the values of all LOCALs and WATCHes, which 95%+ of the time lets me immediately zero in on and fix the problem branch, without having to trace at all. Then, if I still have to trace I can start again at that branch. Quicker and simpler. Yes, a small percentage of the time LOCALs and WATCHes aren't enough, and I have to start from the top of the routine but overall I'm faster doing it this way.

Unfortunately, the part of my post relating to the "blanket" condemnation of multiple exit points was incomplete. I dig further into the concept of sequential vs. hierarchical logic and the limitations of the former which outlines my objections further.

Some more points:

- "personal preference" holds true only for your own code. If your client wants single exit point, you get to comply.

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

- Final trick question: do you support the use of LOOP in DO...ENDDO?

Regards. Al

>Hi Al,
>
>All interesting and reasonable points of view...
>
>>I'm a firm believer in a single exit point.
>>
>>Debugging - if I have a problem with a function or method I can put SET STEP ON, DEBUGOUT or whatever just before the final RETURN which I know is always at the bottom of the routine. I don't have to search for any other RETURNs. When finished, I remove only one set of debug statements. In contrast, if I was lucky enough to remember, a year later, that I might have multiple exit points in my own code that would be a PITA. If I was debugging someone else's code that might have them, that would be PITA^2.
>
>I'm not a big user of the debugger, but when I do I find it convenient to put SET STEP ON either just before a subroutine is called or at the very top of the subroutine. So easier debugging is not an issue for me.
>
>>
>>Maintenance - I find it easier to re-trace the logic with just a single exit point. One compelling reason here is that if logic gets tricky enough to warrant the consideration of intermediate RETURNs, then almost certainly it should be refactored/broken down into subroutines. If your coding style is sufficiently "atomic" then single exit points always suffice.
>
>Here I have a problem... I simply cannot accept a blanket statement or assumption that multiple exits strongly suggests a need to refactor.
>Sure, I could write my code the way MS writes its CHMs (link to link to link to link until finally the meat is there, but I think that presents an even worse maintenance nightmare.
>By the way, **most** of my code IS single exit point, but I'd guess 10% or so of methods/subroutines do have multiple exits. I'm not saying that multiple exits in any way is "necessary" but rather than multiple exits are NOT all bad and that it does NOT deserve the status of "standard".
>By the way, I personally couldn't imagine tracing a routine starting at the bottom. My head just can't get around that idea.
>
>Finally, to limit your reading to end here I just want to address 'non-trivial logic' part below...
>There's a good chance that non-trivial implies numerous parameters and/or relationships between multiple records/tables. Now checking for those numerous conditions (parameter validations and relationship presences/consistencies) could be delegated to (yet another) subroutine or 2 or 3 or 4 but to what real end?
>And the return(s) would still have to be dealt with, introducing extra logic for the sake of a single exit.
>
>Anyway, my real purpose is to find some good reasons why this (single exit point) SHOULD be a universally promoted STANDARD. None have arisen and, as with much other in this realm, PERSONAL PREFERENCE RULES.
>
>cheers