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

I have to agree with Tom. Sometimes, it's either multiple RETURNS or use
(gasp!) GOTO/TAG. There is no need to use a loop when one is not needed, as
long as you remember that the first condition that causes a RETURN to be
executed ends the procedure. 


Francis Lapeyre
IS Dept. Programmer/Analyst
Stewart Enterprises, Inc.
E-mail: flapeyre at stei dot com 



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Tom Liotta
Sent: Tuesday, August 2, 2005 5:19 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: 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.)