RE: Programming philosophy Was:RPG IV program - comments requested

Scott,

>    Wouldn't your examples also imply that program-described 
>files are a better approach as well?  That way you can not only 
>see what fields are being updated, but you can also see exactly 
>where they are coming from.

I see what you're saying.  As usual, I said half of what I should have, and
twice as much as I needed to.  When I say "intent" I mean to say that the
programmer intended to solve some business problem.  The more the code
reveals the chosen solution to that business problem, the clearer the
"intent."  Historically, the closer we get to the hardware/operating system,
the more obscured the solution becomes.  Imaging how long it would take to
decipher the assembler instructions used by a simple PC application like
EDLIN.  This is what makes abstraction such a powerful tool for writing
programs and solving business problems.  I'm not concerned with which
register I need to store values in, or how many bytes I can read into the
I/O buffer before it overflows, or what columns does a field occupy in a
record.

>Our shop uses naming standards that make it immediately 
>obvious which fields come from which files.  These standards 
>make it impossible for fields in one file to have the same 
>name as fields in another file.

Great!  I only wish that more shops had similar standards (any standards?!)

>With the EXCEPT approach, you now have to go down to 
>the Output specs to see whats affected, so for us, it would 
>make things more difficult to follow.

This is an interesting, fairly common complaint.  I believe that this has
kept modular coding from "catching on" in the midrange market.  Rather than
use /COPY or another program/module ("I can't see the code unless I open
another window..."), we have oodles of inline code that's been copied from
other programs.  This doesn't encourage very modular code.

The alternative, to use many, small and easy to understand modules is
understood to be _the_ way to go in the rest of the programming world.  It
is impractical to have an open window for each function your program is to
perform; this is why naming conventions are so important:
GetBasePrice(ProductCode:Price) is so much easier to follow than
GETPRC(ITM:AMT)  I'm still talking about "intent" here.  If the programmer
who wrote GetBasePrice did it properly, the name reflects exactly what the
function does - Get the base price for the item.  Nothing more.  Not verify
quantities or warehouse availability.  It does one thing and one thing well.
When the maintenance programmer (me) comes along, I should not _have_ to
look inside GetBasePrice to figure out what it does.  The intent should be
clear.

Back to Excpt and O specs:  Yes, you have to look at the O specs to see what
is happening, and yes, this distracts the programmer from the intent of the
code, but I might suggest the following construct:

C* Update if customer has tolls this month                                  
C                   If        STATUS = ACTIVE_G                             
C                   CallP     UpdCusYTDFrmTol(Customer:TOLYTD:TOLAMT:TOLDAT)
C                   EndIf                                                   
                                                                            
ORMaster   E            UpdMasTol                                           
O                       TOLYTD                                              
O                       TOLAMT                                              
O                       TOLDAT                                              
                                                                            
PUpdCusYTDFrmTol  b                                                         
DUpdCusYTDFrmTol  pi                                                        
D Cus_I                         10    const                                 
D YTD_I                         15  0 const                                 
D Amt_I                         15  0 const                                 
D Dat_I                          8S 0 const                                 
                                                                            
C     CusKey        Klist                                                   
C                   Kfld                    Cus_I                           
                                                                            
 * Lock record                                                              
 * ASSUMPTION - THIS RECORD ALREADY EXISTS!!                                
C     CusKey        Chain     RMaster                                       
C                   If        %found                                        
C                   Add       YTD_I         TOLYTD
C                   Add       Amt_I         TOLAMT
C                   Z-Add     Dat_I         TOLDAT
C                   Except    UpdMasTol           
C                   EndIf                         
                                                  
PUpdCusYTDFrmTol  e                               

With something like this, I should not have to go poke around in the guts of
UpdCusYTDFrmTol to figure out what's getting updated.  I can look at the
parameters and clearly see what goes in, right at the eval.  If something is
broken, the business problem (Keep track of the last toll date and
cumulative amounts for quick inquiry performance) is implemented in one
function, and should be easily repaired.

I hope *my* intent finally came through! :-)

Buck Calabro
+---
| 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
+---