Hi guys  (vb 5/6)
Many programmers place private declares of api's in each of the .bas
modules that use them while other programmer's place a single public
declare.
Seems like public declares would use more memory/less code maintenance
while
private declares use less memory but more code maintenance.
Am I in the ballpark on this or are there other considerations ?
Thanks
Wayne

Generally there are three schools of thought:

1) Keep all API declarations on Code Modules (bas) public... no duplication,
smaller exe, compile-time error on duplication makes sure there is no
redundancy. Modularity can be handled by keeping related declarations on
separate Code Modules which are added to a project as needed.

2) Keep all API declarations on Code Modules private. Modularity is  very
easy to maintain since the declarations and the code that uses them will be
on a single module which can be added to an app as needed... but some
duplication is inevitable with a modest increase in application memory
requirements.

3) Type libraries seem to be the latest trend for managing large numbers of
API declarations in an efficient manner.

As for me, I'm the odd-ball. I put the declarations and methods that will
only be used occasionally, for specific tasks, on a Class Module which is
then loaded as needed and cleared when finished... keeps memory requirements
down and provides a high degree of modularity... but the compiled exe size
is modestly larger. I like to think of it as 'scoping' the code and
declarations as tightly as possible.

But remember, too much modularity becomes just as unmanageable as too
little.

--
Mark E Alsop

Wayne,

Keeping the declares in each module that needs it simplifies code
reuse. If you want to use an existing module in another project, you
can just include it, without having to worry about missing declares.

Mattias

________________________________________________
Mattias "BeeZo" Sj?gren    Visual Basic f?r Alla

How so?  What are the pitfalls of 'too much
modularity' ?

Drac

Thanks to Mattias and Mark for suggesting different approaches
to the issue that I am working on.
It's invaluable to hear different view points when doing this type of thing
so that you do not go off and do hours of programming.
Thanks guys
Wayne

Every time we take, say, all the code required to create an application of
some consequence and begin to subdivide it according to some logical
methodology the result is 'more objects' to keep in some ordered fashion.

This process of breaking up a large block of code into smaller manageable
pieces requires looking at what each bit of code actually does and then
finding some verbal/word handle that quickly expresses that functionality...
like: API Common Dialog Operations.

The methodology can be applied to smaller and smaller blocks of code. For
instance the API Common Dialog Operations could become several separate
modules based on just which of the Common Dialog Operations they perform
leading to: API FileOpenSave, API ColorDialog, ...etc. After all, an app is
not likely to need the Color Dialog code when saving or opening a file.

The methodology works just as well on very small sections of code as it does
on very large sections of code... thus the methodology can lead to an
excessive number of small code units unless some 'reasonable' restraint is
used as the means to know when enough is enough.

In a practical world and especially in programming, a certain amount of
redundancy allows us to keep like processes self-sufficient and thus much
more easily ported from app to app.

Programming is a human activity and too many small things, like grains of
sand on the beach, loose all of their individually unique characteristics
and merge into a sea of sand... which in programming would make them
useless. Theories are nice and helpful and often give us a goal but we don't
live in theories, we live in a world where our own limitations are often the
best reference point when deciding just how to go about handling a difficult
task.

--
Mark E Alsop

I'm confused.  I have never seen any growth in module size caused by including
extra declarations, even 100 extra declarations . . .  I assumed this was
because declarations are used strictly at compile-time - have you seen something
different?  If you are talking about having similar functions calling
GetWindowRect, e.g., in several different modules, I agree that there is a need
for some intelligent balancing, but declarations???