Jims, T and C

I ran the test. I put a function into module #4 and ran it 50 times.
Put same function into module #107 and ran it 50 times.

In module#4 it ran .000009 seconds faster, or just over 3%.

With 200 users estimated, in 24 hours, it works out to about 20 cpu seconds
saved per day.

Not a great savings, but I think my theory is good, and I'm going to place
the heavily used code in the modules "at the top"

Neal Z.
--
Neal Z


"Jim Thomlinson" wrote:

I have never heard of the modules not being in Alpha order. Just above the
project explorer is a Folder icon. Toggling that on/off puts the modules,
sheets, ... etc into folders.

As for how do you organize things. I tend to have a module called Globals
where I define all of my globals. If a type def was going to be used globaly
then I would put it in there. If the type def applies to only one module then
I would put it there. The most important thing is to organize things
logically and to be consistent. Put like stuff together. If you have 100
modules then that is getting to the point of being unmanagable. I would be
inclined to consolidate things into fewer modules.
--
HTH...

Jim Thomlinson


"Neal Zimm" wrote:


HI All,
I'm a beginning developer for my first, and a pretty big addin. (over
100 modules) Perhaps you can save me some time in putting a timer on what's
below.

I've noticed that the physical sequence of modules is as you insert them
into the project and not by how you name them. I have NO clue how Excel
accesses the modules and the macros within them.

Within a month, I'll be moving the code to a "QA" project .xla file and
will have the chance to resequence the top to bottom module order.

best practices, are there significant efficiencies to be gained if:
1. Global public variables, record types, are in the modules at "the top" ?

2. The most used Sub's and Functions are in the "earlier" modules ?

3. Should Public Type XXXXX be in the same module as the code which uses
them the most, or doesn't it matter ? (That's where they are now to use the
"split screen" function of the VBA editor.)

Other tips would be appreciated.
Thanks
--
Neal Z