>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+
>
>The original programmer gave up. I took a look at the code; even with
>
>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.
You're gonna lough about this.
The worse i have ever seen (in a large mrp app): they did the following:
do while ...
loop
enddo
As to the multible exit points: i usually do not use multible, but sometimes it makes life easier and more readable. However, when i do, i usually try to do them before all of the main code starts.
Just my 2c
