RE: Small subroutines WAS:RPG Indicators

Dan Bale wrote:

>> The other rule of thumb I try to stick to is to have read 
>>loops no longer than can comfortably be seen on one 
>>SEU screen.  If I have more processing  than can be 
>>done 'between the reads', I typically move it into a
>>subroutine.
>
>And, so, now you have to go find that subroutine in another 
>place in the source, which is _still_ more than one screenful.  

This problem is way worse in RPG III than RPG IV because of the short name
restriction.  If the name were more reasonable you wouldn't have to look at
the source of the subroutine to figure out what is happening in it.
Procedures make this even nicer because you can see at a glance what
variables are modified by looking at the function call.  You don't have to
dip into the source with a dowsing rod to try to figure out what variables
are being returned to the caller.

>Finding the matching EndDo is, potentially, only more of a 
>problem (than finding the EndSr) if it's not documented 

Those darned nested ENDs!  This is very typical in first generation RPG III
code.  Lord knows I've created my share!  I've been better lately by
thinking it out better.  Mixing decisions and actions (read / record found /
process record) tends to encourage deep nesting because the "process record"
bit tends to have further decisions, etc...  Put the action in a procedure
and you avoid making the nice clear Read loop into a mess.

>(RANT MODE: ON)
>It drives me crazy to to have to jump around in subroutines 
>nested ten or more levels deep.  And the three statement 
>subroutines?  What are these geniuses thinking of?
>(RANT MODE: OFF)

In the olden days when we had to pay for every line of code, BEGSR and ENDSR
cost us two extra cards.  We didn't spend money on those cards unless it was
cost justified by using those cards to reduce card usage elsewhere.  That's
how we came to think of subroutines as purely "places to put repeated code
snippets."

Now, I would argue that it makes much more sense to create many small,
simple, easy to understand procedures.  The name and prototype should be all
that you need to look at.  If it's named right, it's automatically easy to
understand.  This is where we should focus our standards efforts.  Ban the
use of 500 line long "exsr ProcessRecord!"  No wonder I had to look at the
subroutine code to figure out what is happening there!  Instead, put a dozen
small procedures into ReadRecord, where each procedure does One Simple
Thing.

Also, Much Grief is caused by the hideous inadequacies of SEU.  The closest
SEU comes to a bookmark is to write down line numbers on a scrap of paper.
Code/400 and Flex/Edit both offer easy to use bookmarks.  Jump to the
definition and right back to the procedure, or open them in separate
windows.

Buck Calabro
Aptis; Albany, NY
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---