How many modules is too many?

[Lauren Quantrell]

At running the risk of asking how big is too big...

Is there a rule of thumb or a best practice that says I may have too
many modules? I currently have a Access2K app with about 30 code
modules, plus of course the modules associated with the forms
themselves.

My practice has been to create a seperate module to handle specific
groupings of code, for example, a seperate module to handle clipboard
actions, window sizing actions, etc.

Any guidence is appreciated.

lq

[Brian Wilson]

"Lauren Quantrell" <la*************@hotmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

At running the risk of asking how big is too big...

Is there a rule of thumb or a best practice that says I may have too
many modules? I currently have a Access2K app with about 30 code
modules, plus of course the modules associated with the forms
themselves.

My practice has been to create a seperate module to handle specific
groupings of code, for example, a seperate module to handle clipboard
actions, window sizing actions, etc.

Any guidence is appreciated.

lq

If you asked yourself the question "What advantage would I get by merging
some of these modules together to give fewer modules with more code in
them?" Then I guess the answer would be "None".
Grouping bits of code into modules is the way most sensible developers do
it, although I usually have a module where the code chunks are only linked
by the fact that you need them all the time, e.g. IsFormLoaded, TableExists,
etc.
Of course I haven't seen the code, but 30 modules doesn't seem unreasonable.

[David W. Fenton]

"Lauren Quantrell" <la*************@hotmail.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:

At running the risk of asking how big is too big...

Is there a rule of thumb or a best practice that says I may have
too many modules? I currently have a Access2K app with about 30
code modules, plus of course the modules associated with the forms
themselves.

My practice has been to create a seperate module to handle
specific groupings of code, for example, a seperate module to
handle clipboard actions, window sizing actions, etc.

I tend to make class modules very focused, but not segregate
funcitonality in modules too much, unless there's a group of
functions that are interdependent and are always used together.

For instnace, in one app, I have a module that's entirely dedicated
to supporting the upload of data to the client's website. The
functions are called in two forms, and they are interdependent on
each other.

But standalone functions I put in a general module for the
application.

I do have two main modules that I start from, one called mdlDWF, for
code that I've pulled into an applcation from my personal code
library, and the other called mdlApplicationName, where I put code
specifically written for that application.

Those two modules are the starting point in any of my apps.

I then add other modules when I need to write a segragated group of
fuctions/subs as in the example above, or when I'm importing someone
else's code, say a dawnload from the Access Web. And class modules,
of necessity, stay segregated by purpose.

Just looking at a moderately complex app of mine, I have 11 modules
and 12 class modules. In another somewhat less complicated app, I
have 14 modules and 7 class modules. In another relatively more
complicated app I have 13 modules and 16 class modules.

So, I wouldn't say that 30 class modules is out of hand at all,
especially if some of those are class modules. It all depends on the
level of complexity of your application.

In contrast, an app I took over from a client (it was done by a
non-Access programmer, but his work would put many professional
Access developers to shame, with excellent coding practices). The
one thing about the app that is annoying is that there was a
tendency for the developer to create one module per
function/subroutine. I have never bothered to consolidate, though,
as I don't see that it makes much difference.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Bri]

Lauren Quantrell wrote:

At running the risk of asking how big is too big...

Is there a rule of thumb or a best practice that says I may have too
many modules? I currently have a Access2K app with about 30 code
modules, plus of course the modules associated with the forms
themselves.

My practice has been to create a seperate module to handle specific
groupings of code, for example, a seperate module to handle clipboard
actions, window sizing actions, etc.

Any guidence is appreciated.

lq

I seem to recall reading somewhere that modules are loaded into memory
on an as needed basis (this assumption is subject to some else out there
knowing more about it than I do). So, if the function/subs that are
likely to run together are grouped into modules, then if a user is only
working in one part of your app he/she doesn't have to have all of the
code loaded into memory. With today's PCs having so much RAM this may
not be the big deal it was in the past.

I also create separate modules for API related functions. These have so
many declarations and constants related to them that it would be
confusing to mix them in with other code and/or other API functions.

--
Bri

[Lauren Quantrell]

Thank you everyone for your input on this. Hopefully this informnation
will be helpful for others having the same questions. I pretty much
stick to the same practices outlined by Bri and Don - I have a module
that is used for startup functions associated with the application's
loading, one for frequently used or common functions, and seperate ones
for anything involving API calls because of all the constants and
declarations.
So I guess 30 or so modules for an application having 50-75 forms is
not unreasonable not wasteful in terms of resources.
Thanks one and all.
lq

[David W. Fenton]

Bri <no*@here.com> wrote in news:9vB0f.84150$oW2.17414@pd7tw1no:

I seem to recall reading somewhere that modules are loaded into
memory on an as needed basis (this assumption is subject to some
else out there knowing more about it than I do). So, if the
function/subs that are likely to run together are grouped into
modules, then if a user is only working in one part of your app
he/she doesn't have to have all of the code loaded into memory.
With today's PCs having so much RAM this may not be the big deal
it was in the past

I don't think this is the case any longer with the monolithic save
model introduced in A2K. I can't see how it could be.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Bri]

David W. Fenton wrote:

Bri <no*@here.com> wrote in news:9vB0f.84150$oW2.17414@pd7tw1no:

I seem to recall reading somewhere that modules are loaded into
memory on an as needed basis (this assumption is subject to some
else out there knowing more about it than I do). So, if the
function/subs that are likely to run together are grouped into
modules, then if a user is only working in one part of your app
he/she doesn't have to have all of the code loaded into memory.
With today's PCs having so much RAM this may not be the big deal
it was in the past

I don't think this is the case any longer with the monolithic save
model introduced in A2K. I can't see how it could be.

You could very well be right as I'm sure I read this long enough ago
that it probably was referring to AC97. It could also explain some more
of why AC2K is so slow.

--
Bri

[david epsom dot com dot au]

There is a number which is "too many", and you
might eventually find it, but I can remember from
the previous discussion that "30 + forms" is way
smaller.

The person who reported hitting the limit had a
separate module for each procedure, and a lot of
procedures.

Each module is loaded was loaded as an object, so
if you have hundreds or thousands of modules each
would be loaded separately, so the loading and
finding of procedures would take longer.

Of course that was in a previous version of Access,
and the limit might have changed.

Doubtless there is also a limit on the number of
lines in an individual module.

Whatever the limits are, they don't interfere
with normal coding practice. 30 code modules is
with the limits of normal coding practice. 1 module
is not, and 1000 modules is not.

(david)

"Lauren Quantrell" <la*************@hotmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

At running the risk of asking how big is too big...

Is there a rule of thumb or a best practice that says I may have too
many modules? I currently have a Access2K app with about 30 code
modules, plus of course the modules associated with the forms
themselves.

My practice has been to create a seperate module to handle specific
groupings of code, for example, a seperate module to handle clipboard
actions, window sizing actions, etc.

Any guidence is appreciated.

lq