Personally I try to avoid multiple returns, however I must say that sometimes I use them to prematurely leave the routine (checking conditions) before the beef of the procedure starts.
Within the beef of a procedure I think that multiple returns could end up with a major headaches esspecially when doing revisions and maintenance. From the literature writing a piece of code should be done more or less like the following
Initialize --> The procedure body --> Cleanup.
With multiple RETURNs the cleaning up task might become far more difficult and is a big potential source of bugs.
When in the initialisation some settings are made (for example: THISFORM.LockScreen = .T., BEGIN TRANSACTION, SET DELETE OFF, ETC), you want to make sure they are restored when the procedure is exited. Copying and pasting the cleanup code just before each RETURN IMO is not making the program either more readable or less suspectible to errors. When introducing TRY ... CATCH .... FINALLY to your procedure you cannot use intermediate RETURN at all and have to rework your code to eliminate your returns anyways
An example of terribly designed code with multiple RETURNs is the RI code that VFPs RI builder creates (would be a good lesson to anyone, how not to code). You'll see 5 or 6 lines of cleanup code before each intermediate return. The TAXRI builder creates only one main procedure for the whole RI with only one exit point at the end of the procedure. IMO, it does not only make your code way more compact (The more RI relations the more TAXRI saves in code lines) but way and way more readable.
again.
Initialize --> The procedure body --> Cleanup.
When I went to university this was one of the first rule I was told and I guess this what they will tell you on each programming course. I've taken this rule as part of my programming style. For those who argue that they can make their code more readable with intermediate RETURN I disagree in the sense that it might be more readable to them, but a nightmare to someone else. Readability seems way more a personal preference than anyone thinks.
Personally, I'm way more confortable with knowing that the procedure ends at the bottom, and I really dont care about a few more indents because an IF/ENDIF or DO CASE is needed. This brings me to the remark that the DO CASE is a construct that seems to be really undervalues by programmers:
Often forestanders of the intermediate RETURNs complain about having to read the whole code while an RETURN could save you the reading. Why does this not apply to
IF Y=1
IF X=1
ENDIF
IF X=2
ENDIF
IF X=3
ENDIF
ELSE
IF Y=2
ENDIF
ENDIF<PRE>
Which can be easily reworked to
<PRE>DO CASE
CASE Y = 2
CASE Y <> 1
CASE X = 1
CASE X = 2
CASE X = 3
ENDCASE
And has not the disadvantage that you have read all X comparisons. If one matches, just exit the DO CASE from there.
In regards to LOOP and EXIT, yes I agree they are not neccesary. You can always work arround the use. I never use them because it disturbs my readability (while others might feel it helps them). Often LOOP and EXIT have the same technical disadvantages as mentioned for RETURN because of:
Initialize --> The body --> Cleanup.
Well, we could ask why there are so many people using intermediate RETURNs, LOOP and EXIT. I'm just a bit too young to know the exact cause, but I do know that when I started programming in FPD 2.0, I had to deal with many older people comming from CLIPPER. About all had a coding style that was very simular to the pseudo code often used in JSP (Jackson Structured Programming) which identified tasks and often resulted in multiple pages spanning DO WHILE constructs and frequent use of EXIT, LOOP and intermediate RETURNs. The created code often contained many repeating codeblocks that really should have been placed in seperate procedures or functions. Today with OOP we seldom should create such long and terrible constructed, difficult maintainable and readable code. In clipper those long do while constructs where about data retrieving or processing that now can be handled much more efficient and readable with powerfull xBase DML or SQL commands.
Nontheless, I might be wrong here and I might offend people by saying this, but it is my opinion that people using these constructs have learned that from long in the past using older tools. I get the picture that the somewhat younger (or more recent) educated programmers are less tempted to use them.
However I think it is important to say that with and without use of these constructs it is possible to create both terrible and good code. So I don't agree with someone saying that a programmer using this construct is not a good programmer. However this programmer should be aware of situations (as described above) where the use of such construct could get messy when the code needs to be enhanced or maintained. I spend more time on formatting the code in a readable, efficient and maintainable construct than I spend time on coding the solution itself. I'm not going to say that it is always easy, but I find it pays off in the long term when after a few years I've got to dive into the code again and find out what it does and how to extend it.
Walter,
