|
midrange.com
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
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
