RE: No Subroutines (was Re: Debugging many subprocedures)

This thread seems to have faded, but I have some thoughts on some of the 
fundamental reasoning -- in-line...

rpg400-l-request@xxxxxxxxxxxx wrote:

>Having multiple RETURN's is not good practice.  This was drilled into our
>heads back in the first year of college.  It was just like using
>GOTO's--you just don't do it because there are other constructs to handle
>it.

Why is it not good practice? I'm not so much a proponent of multiple RETURNs as 
I am of clear reasoning. I'm bothered by the reasoning described here. Why is 
the above reasoning any better than "Use another RETURN rather than other 
constructs because RETURN is designed to 'return' where other constructs 
provide a more obstructed path to an eventual RETURN. I.e., use the feature 
that's designed for the task."?

To base a principle on something such as "...because there are other constructs 
to handle it" seems needlessly complicating. Note that this is simply a 
question about what the reasoning _means_, not an attack on the principle 
itself. (And do CS-101 courses actually teach such things as this as 
fundamental principles? It wasn't drilled into my head in college, IIRC, but 
that was... ummm... well... more than 30 years ago.)


>  There is only one entry point into a procedure/subroutine and there
>should be only one exit point.  Having more than one adds potential
>confusion and detracts from readability.  It might be easier to code but it
>may not be easier for someone else to maintain years from now.

And why is the above reasoning any better than "Provide a dedicated and 
commented code-block at the beginning of the procedure to handle exception 
RETURNs for as many cases as needed. Having this adds clarity and increases 
readability particularly for the procedure code that implements the procedure 
purpose.  It might be easier to code and it may be easier for someone else to 
maintain years from now."


Since programming has quite a bit of logic and reasoning involved (even in RPG, 
to satisfy minimal on-topic requirements), it seems to me that a group of 
professionals ought to be able to come up with convincing reasoning one way or 
another. Both sides on this issue have given good reasons, so there doesn't yet 
seem to be a Programming Law that holds up.

And to me that indicates that this is an issue of balance. Good practice, then, 
would be to code with a single RETURN until the code structure begins to 
obscure the purpose of the procedure (and there are gradients there). Then 
restructure the code so that those pieces that essentially do nothing but say 
"This isn't for me; RETURN" are grouped cleanly and clearly at the top. Once 
that's done, nothing below that point should do anything but implement the 
procedure purpose.

The procedure purpose is what it's all about, isn't it?

Tom Liotta