RE: Function Opinion

Booth,

On Thu, 2003-10-16 at 17:04, Booth Martin wrote:
> So far Roy no one has discussed performance; only technique and style. 
>  
> What are the facts on what happens in the various scenarios? Is there a
> difference in the compiled application if one has included dozens of unused
> modules vs. spending the time and energy to be sure only those modules
> needed are included?

There is really no such thing as an included-but-unused module.  If a
module is bound into a program then it is used by that program.  What
you probably mean, and I'm not trying to argue semantics here just
clarifying, is whether or not there are unused procedures within a bound
service program.  That answer could easily be yes.  Is it going to
affect performance?  In a word... maybe.  If you have a monster service
program, say a hundred procedures, and you are only using one, you still
incur the overhead of opening all 100 procedures when you open the
service program.  Is it a lot of overhead?  I'm honestly not sure, but I
do have some service programs with 20+ procedures and I haven't had any
problems yet.  

The real beauty here is that that penalty will NOT increase if you
decide to use 57 of those procedures, so in theory you can expand inside
that framework without suffering.

> Coding styles and standards are important of course but what worries me is
> that the idea of black boxing solutions for everyday problems seems to be a
> casualty in this discussion.  It would seem to me that the end game is to
> provide a simple and well documented means for a shop to provide tested and
> error-free solutions to everyday programming problems. It seems obvious from
> the amount of interest, the variety of opinions, and the length of this
> discussion that the Service Program algorithm is neither simple nor clear. 

There certainly are a lot of different ways to approach it, but having
the options is a good thing.  I think of paramount importance is that
within your own shop you establish a consistent set of rules and enforce
them.  I know, I know, easier said than done, but if that can be
established then the truth is that most of the methods we've bandied
about here will be sufficiently effective.

> Here is an instance where we really don't care about efficiency in my
> opinion, we only care about effectiveness. Effectiveness includes such
> things as ease of documentation, ease of training, ease of use, ability to
> find existing code and reuse it, and the ease of passing on knowledge to new
> staff members as they come on board.

I couldn't agree more.  I've developed the method I use because I think
it is the best way for a microscopic staff like mine to manage our
software.  As a result, I tend to focus on functionality over
performance and I think I've come up with a nice blend of effectiveness
and efficiency.

Just my $.158

Joel
http://www.rpgnext.com