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

On Tue, 2005-08-02 at 18:19 -0400, Tom Liotta wrote:
> 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."?

I see the 'no multiple returns' as a good idea, not necessarily a firm
rule.  In the same way that lots of goto's make a program hard to read,
understand, and debug, so do returns sprinkled everywhere also make a
program hard to read, understand, and debug.  And more importantly -
harder to extend during the maintenance cycle.

IMO, it seems the human mind is quite good with the type of continuity
that you see in a book, e.g. start at page one, and read each page in
succession until you get to the end.  We even deal fairly well with
occasional jumps to other sections, especially if they are to a nearby
target (e.g. 'see figure 1').  

However, if I were forced to jump all over the book every few lines of
text, I would soon tire of it and quit reading.  I would like my
programs to be as easy and straightforward to read as a book.  One way
to do that is to limit the use of constructs that make the program more
difficult to read and understand.  Which is quite an easy thing to say,
not so easy to do.

I think a few well thought out returns can be fine.  An occasional goto
might be all right.  But, in general, minimize their use as much as is
practical.

There was a mention of using returns as a guard at the beginning of a
function, which seems reasonable.  It seems even more reasonable to
break the routine into two.  I've heard it mentioned that a function
ought to do one thing, and one thing only.  

It seems that the imaginary functions that might need a bunch of returns
at the beginning should be described as 'Validate the incoming
parameters AND compute some magic thing'.  If that's the case, perhaps
the validation portion can be spun off as a separate routine, and in the
process obviate the need for a bunch of returns:

A short example (not drawn to scale)

The imaginary compute routine, with returns:

D compute             b
D compute             pi            10a
D  parm1                            10a
D  parm2                            10a
D  parm3                            10a

D  result             s             10a
 /free
    if parm1 <> 'foo';
        return;
    endif;

    if parm2 <> 'bar';
        return;
    endif;

    if parm3 <> 'baz';
        return;
    endif;

   
    // do the magic here

    // now return the result
    return result;
 /end-free


The imaginary compute routine, broken down into two routines, one that
validates, and the other that performs the actual computation:

D compute             b             10a
D compute             pi
D  parm1                            10a
D  parm2                            10a
D  parm3                            10a
D  result             s             10a
 /free
    if compute_validate(parm1: parm2: parm3);
  
        // do the magic here

    endif;

    return result;
 /end-free


D compute_validate    b               n
D compute_validate    pi
D  parm1                            10a
D  parm2                            10a
D  parm3                            10a
D  result             s               n
 /free
    if parm1 = 'foo' and parm2 = 'bar' and parm3 = 'baz';
       result = '1';
    endif;
    return result;
 /end-free

Which is more readable?  Which is 'better'?  I think it depends on your
preference.

Regards,
Rich