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

Yeah, it was drilled into my head to...got the BS in CS to prove it.

But experience with some of the hoops I've coded to jump through in order to 
have only one return has made me reconsider.

As a maintenance programmer, I'd much rather deal with multiple RETURNs instead 
of nested IFs.

With a return it is obvious that the procedure ends right there given some 
criteria.  With an if, you have to follow it through, look for a else and see 
what else the procedure may be doing that is going to affect something.

As I mentioned in a prior post, my motto is "don't surprise me with a return".  
So you'll either see a single return, or "lots" of returns.  By "lots", I mean 
that the code logically structured to use multiple returns.  Might only be two, 
but the extra won't be stuck in the middle someplace where it would surprise 
you.

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of
> daparnin@xxxxxxxxxxxxxx
> Sent: Thursday, July 28, 2005 12:21 PM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: No Subroutines (was Re: Debugging many subprocedures)
> 
> 
> 
> 
> 
> 
> 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.  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.  Just my
> $0.02.
> 
> Dave Parnin
> --
> Nishikawa Standard Company
> Topeka, IN  46571
> daparnin@xxxxxxxxxxxxxx
> 
>