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

I should have said IME for sentences 1 and 2 (see below for example). I don't see how you can argue with sentence 3.

>
>>
>>Continuing with the Maintenance argument, I find it easier to enhance routines that have single exit points. A style I use is to *always* have an ELSE clause if there's an IF, even if it contains only a comment (e.g. "Variable X assumed to have value YY"). This achieves two things:
>>
>>- Proves to others reading your code that you have considered the alternate branch, and what assumptions you made
>
>Or shows that someone simply has a habit to put IF ELSE ENDIF...

?? Is my point invalid?

>
>>
>>- Provides a pre-built entry point for future enhancements.
>>
>
>I can agree to that.
>
>>Now, diving into the realm of pure speculation and opinion < g > I ponder the thought process of someone who would use multiple exit points to implement non-trivial logic. I believe it reflects the use of sequential thinking, rather than hierarchical.
>
>There are places for both types of thinking.

Yes, but one of my main points is that sequential thinking runs out of gas earlier. If you have to enhance later, you've got more headroom if you start hierarchical. This argument has some analogy to the use of OO vs. procedural code in VFP.

>
>>I hope it seems completely natural to write the code as a multi-pass parser. Fundamentally, it's the way a human thinks, and more closely matches the way the data are structured. Sequential thinking is the mark of a machine. It works in some cases but IME you hit the wall a lot earlier than with hierarchical logic.
>>
>>So, IME the use of intermediate RETURNs indicates sequential logic, which is suspect at best and hard to enhance at worst.
>>
>>As a final note, I don't believe in using LOOP in a DO...ENDDO either; I consider the practices equivalent. It would be interesting to see if anyone pooh-poohs the use of LOOP, while advocating intermediate RETURNs.
>
>Since this discussion started, I'm finding my "rule" is to use the multiple exits to get out before I start the meat of the problem.

Your "rule" cries out for refactoring. I would much rather:

IF NeedTheMeat(< params list >)
  * We're at the "meat" right away
  llRetVal = MeatRoutine(< another params list >)

ELSE
  * According to the input parameters, no meaty stuff required:
  llRetVal = < default return value >

ENDIF

RETURN llRetVal

FUNCTION NeedTheMeat
... nicely structured with a single exit point, of course < g >

>
>Likewise in DO...ENDDO, I think it very sensible to use LOOP to skip records, before letting the rest of the stuff inside the DO...ENDDO fire.

See the example at the bottom of my reply to Jim.

>
>I don't want to read down the code until it's necessary. IMO, focusing the reader on the heart of the matter, is the essence of readability.

FAR more important is to make your logic as obvious as possible. Where this is in conflict with "focusing", obviousness must prevail. To take your concept to a ridiculous extreme:

FUNCTION DoSomeStuff()
* There's only one place to look - we're "focused". You can be the judge of readability:
RETURN IIF(SomeFunc1(), SomeFunc2(), IIF(SomeFunc3(), SomeFunc4()... ))