Declaring variables in Module vs. Public

[Jeff]

Hi,

I have written code and there are a number of variables that are declared at
the top of the module - so they can be used by all subs in the module.

I am expanding the code and am considering separating the new added code
into a different module because it would be organized a little better.

My question is - is there a performance difference to declaring the
variables public rather then "Module" wide. Any advice under what
circumstances to break code into different modules and when to declare public
vs module wide.

I have 1 module now, but I could break up the code into 6 modules that have
product specific data. All the variables would have to change to public
because they are common in the 6 modules.

Thanks for your help

 

[Bob Phillips]

There is a difference, because the variables will be in scope for the whole
project, but in reality you probably won't notice it. There is a bigger
question over design, structure, etc., but by going to multiple modules you
are starting to think along the right lines.

--
---
HTH

Bob

(there's no email, no snail mail, but somewhere should be gmail in my addy)

 

[Jim Thomlinson]

There is no performance difference by splitting up one module into multiple
modules. There is no performance difference between having private vs public
declarations. Where the difference arises is in scope. I follow the rule that
you always keep the scope of a variable as small as possible. The wider you
make the scope the more difficult that it becomes to debug the value if
something goes wrong. Additionally I avoid having global or module wide
declarations with a passion. My current project has over 3,000 lines of code
and only 4 such declarations. In most circumstances global or module wide
declarations can be avoided by passing values from one procedure to the next.

When should you break code into seperate module. Whenever it makes logical
sence to do so. Each module should perform a single set of tasks , such as
you might place all of your printing routines in one module and all of your
sorting routines in another. Quite often I will have one module that I use
for utility functions used by procedures in multiple modules... Whatever
makes sense and helps you to keep things organized is what is best.

 

[Jim Thomlinson]

I think I bench marked different declaration scopes at one point and found
that there was really no difference in performance (can't rememeber if I
checked global between modules). Even global vs locally declared showed
pretty much no difference (I had expected to see a difference here since the
variables would need to be added and removed from the stack when declared
locally). Did you find something different?

 

[Jeff]

I have not seen a difference in performance.

It is really a question of balancing two things

Splitting up the code into modules - more organized, but more variables are
public.

vs. keeping all code in one module - more disorganized but all variables are
declared in one module.

I think overall from what I am hearing from the respones is that splitting
up makes more sense.

Thanks for your input.

 

[Jim Thomlinson]

You are right on. Keep things as logically organized as possible. Name your
modules to describe what is in them.

I also recommend keeping your varaibles as private as possible. The more
procedures that have access to change things the more things you need to look
at when something goes wrong...

PS I just rechecked my results and found no real difference between private
module and global varaibles. When the variables were locally declared within
the procedure as opposed to declared globally there was almost no difference
(less than 0.25 seconds on 100Million ittereations)...