RE: Benefits of Sub-procedures

[James Rich <james@xxxxxxxxxxx>]

On Fri, 24 Oct 2003, DeLong, Eric wrote:

> I never saw "module should have one procedure" as a goal.  That's but one
> possible way of approaching this.  I myself advocate grouping of similar
> procedures into a single source member / module, which would then usually
> become its own service program.  I don't like module objects lying around,

I think this is probably the most common way of doing things in other
languages (i.e. many related procedures in one source member).  For
example, the tn5250 code (in C) for implementing *SCS print support to
PDFs has this:

in scs.c:

/* Device control */
void scs_sic (Tn5250SCS * This);
void scs_sea (Tn5250SCS * This);
void scs_noop (Tn5250SCS * This);
void scs_transparent (Tn5250SCS * This);
void scs_spsu (Tn5250SCS * This);

/* Page control */
void scs_ppm (Tn5250SCS * This);
void scs_spps (Tn5250SCS * This);
(etc......)

This file (scs.c) is compiled to an object file which is combined with
several other object files to create a "library" (totally different
meaning than on the iSeries.  Here library is the same as a service
program).  scs2pdf.c is the source file that contains the main body of
the program that actually does the conversion to PDF.  It also has many
functions in it.  scs2pdf.c includes (or /copy in iSeries parlance) a file
which contains the definitions of the functions in scs.c so that it may
use them.  scs2pdf.c is compiled to an object file which is then
dynamically linked to an executable.

This way of grouping like functions in one source file and then grouping
related objects into one "service program" is very common.  Whether ir not
it is "best" practice is up to you.  It is at least common practice.

James Rich