**
Nuts. I hit enter before I finished and I got a reply before I could finish the update. Ignore the earlier post; this one is correct.
**

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.

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.

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

- Provides a pre-built entry point for future enhancements.

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.

Like Evan, I first started using the single exit point concept as the result of working on a "project from hell" written by someone else. The project was to record doctors' caseloads using portable bar code scanners. The idea was that in the course of a day, a Doctor would see multiple Patients, perform one or more Activities on each Patient, with one or more time codes (hours or minutes) associated with each Activity. At the end of the day, each Doctor would give her scanner to IT who would download the scanned codes and parse them out into Doctor/Patient transactions ready for reporting.

The parser was originally written as a single-pass parser, using sequential logic. It made one pass through the list of bar codes from start to finish. It made extensive use of intermediate RETURNs and LOOPs within DO...ENDDO. It worked fine.

Unfortunately, the real world intruded. To cut costs, more than 1 Doctor had to share a scanner. Much worse, it was soon discovered that sometimes Doctors would double-scan codes, miss them entirely, or scan out of the expected sequence.

So, the one-pass parser had to be enhanced to add another *possible* level of structure (couldn't assume it was all 1 Doctor any more). And, it had to be enhanced to handle all possible mis-scans gracefully, retaining as much valid information as possible to minimize the re-scanning the Doctors would have to do the next day.

Now imagine it's early 1990 and it was FoxBASE+. Debug and trace tools were less sophisticated than today. Even with the original programmer available beside me I found it almost impossible to trace the existing code, much less figure out how to enhance it as required.

I eventually rewrote it as a hierarchical multi-pass parser. First it looked for Doctors in the code list, then successively parsed out Patients, Activities, and Time Codes. It was not difficult to ignore duplicate scans, use placeholders for missing scans and handle (in some cases, even automatically correct) scans made out of sequence. It was maintainable and fast. Everyone loved it.

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.