RE: Procedure names vs. production support

Rick,

If you have to test every procedure in a module when one is changed, the I can 
see why you'd push for one procedure per module.

However, IMHO that is a ridiculous requirement.

The whole idea behind procedures is that a change in one has absolutely no 
effect on another stored in the same module.

UNLESS you are using global variables.

The only thing to be concerned about it accidentally changing a procedure you 
didn't intend too.  Such concerns can be easily dealt with by using a source 
compare utility to prove that the only procedure you changed was the one you 
intended to change.

Proper modular programming leaves you with lots of small procedures.  Having 
one per module, is quickly going to overwhelm you when it comes to binding them 
into (service) programs.  

How about prototypes for those procedures?  If you keep one prototype per 
module, you'll quickly end up with more /COPY lines than code.


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
> Rick.Chevalier@xxxxxxxxxxxxxxx
> Sent: Thursday, February 17, 2005 4:09 PM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: RE: Procedure names vs. production support
> 
> 
> 
> Charles,
> 
> I agree on the self documentation aspect.  That's my main 
> argument against that method and for option 1.
> 
> I guess I'm the one person that likes the one procedure per 
> module idea, at least here.  The reason is testing.  I've 
> been trying to sell this concept since I joined the company 
> almost three years ago.  One of the primary objections has 
> been that we would have to test everything anyway whether we 
> used modules or not so why bother.  If the source for 
> multiple procedures is in a single member management will 
> require that each procedure in the source be retested whether 
> it has been changed or not.  This adds to the testing load.  
> If each procedure is contained in a separate module with 
> separate source you have isolated the testing task to just 
> that object.
> 
> Rick
>