RE: Function Opinion

[Rich Duzenbury <rduz-midrange@xxxxxxxxxxxxxxxxxxx>]

At 09:22 AM 10/16/03, you wrote:
> I have a question about testing with this method.  In our shop, if I have 
> multiple procedures in a single source member that compiles into a module 
> and I change one of the procedures or add a new procedure I will probably 
> be required to test every procedure because the source changed.  How do 
> you handle this?  Can you get by with testing only the changed/added code?
>
> Because of this testing requirement I lean toward making each procedure 
> it's own module.

Hmm.  For example, lets say I have a module full of date routines, and I 
come across a need for a new function, say to find out what date is the 
first Monday of the month.  I update (in a test library) /COPY book to have 
the new procedure interface, and I update the module code, and recreate the 
service program.

In most cases, I then create a small test harness program that shows how an 
example call would look and work, which I then actually call to try out the 
new function.  This also comes in handy when I forget how to code up the 
function call for another program at later time.   It also lets me know if 
my interface is clumsy to use, in which case, I might change it a bit at 
this point.

Then I use some judgement.  If I haven't disturbed any of the other 
functions, I probably won't go to much trouble to do a lot of testing.  If 
I'm feeling paranoid, I run my other test harnesses to make sure everything 
still works.

Once I'm happy with the new code, I arrange to get it into production.

Since I am grouping like functions, I do tend to automatically limit the 
number of functions per procedure.  I would perhaps be a bit concerned to 
see hundreds or thousands of procedures in one module.  I like to keep it 
in the tens of procedures or less.  One procedure per module seems a bit 
extreme in that you may need a large number of source members on even a 
moderate size project.

As they say in the Perl World: TIMTOWTDI (There is more than one way to do it).

Regards,
Rich