declare vars at module level or pass as args?

[Anonymous]

Hi,
Is there a rule of thumb to decide whether to declare variables at module
scope so all proceedures in that module can use them or whether to write all
proceedures to accept args and pass the vars around that way?
Like if I have seven or so vars and several subs or funcs need to mess with
them variously are there overhead considerations like passing args uses more
memory than storing vars in module scope or???
or speed of execution? or ease of writing? or ease of understanding code?
I've read that 'global' variables as bad and in a way I guess I've thought
that module level was kind of 'global' but it seems that in vba since
there's different levels of scope available that it's not totally
unacceptable to have a variable other than inside a proceedure and,
therefore, to have to pass any values around as arguments and return values.
Or maybe I'm totally misunderstanding all this scope stuff and global
variables being a bad thing???
any suggestions?
Thanks
Mark

[Anonymous]

Hi Mark,

This is a great question. I hope you (and I) get a meaningful answer.

Anecdotally in the programs I write I have not noticed any difference in
behviour.

I tend to define variables at modular level and pass them to functions until
such time as:
I find I'm passing the same thing from function to function to function
or I am passing too many variables to any given function and I get confused
as to what they all are.
Occasionally I resolve this by putting the individual elements in an array
and pass the array.

I then define the variable at form level - or globally as seems appropriate.

I use a very structured variable naming process, so that I know the scope of
a variable simply by looking at it.

eg

sVariableName is a local string
sfVariableName is a form level string
saVariableName is a local string array
safVariableName is a form scope string array
sagVariableName is a global scope string array

spVariableName is a string passed as a parameter
sapVariableName is a string array passed as a parameter

--




Laurie Comerford
CADApps
www.cadapps.com.au



"MP" wrote in message
news:789CE53E17E23FCF894625EBD49CB69B@in.WebX.maYIadrTaRb...
> Hi,
> Is there a rule of thumb to decide whether to declare variables at module
> scope so all proceedures in that module can use them or whether to write
all
> proceedures to accept args and pass the vars around that way?
> Like if I have seven or so vars and several subs or funcs need to mess
with
> them variously are there overhead considerations like passing args uses
more
> memory than storing vars in module scope or???
> or speed of execution? or ease of writing? or ease of understanding code?
> I've read that 'global' variables as bad and in a way I guess I've thought
> that module level was kind of 'global' but it seems that in vba since
> there's different levels of scope available that it's not totally
> unacceptable to have a variable other than inside a proceedure and,
> therefore, to have to pass any values around as arguments and return
values.
> Or maybe I'm totally misunderstanding all this scope stuff and global
> variables being a bad thing???
> any suggestions?
> Thanks
> Mark
>
>

[Anonymous]

I prefer to pass arguments to functions. Doing so allows me to control
access to a given variable which makes it easier to track down bugs.

--
Good judgment comes from experience.
Experience comes from bad judgment.

http://www.acadx.com


"MP" wrote in message
news:789CE53E17E23FCF894625EBD49CB69B@in.WebX.maYIadrTaRb...
> Hi,
> Is there a rule of thumb to decide whether to declare variables at module
> scope so all proceedures in that module can use them or whether to write
all
> proceedures to accept args and pass the vars around that way?
> Like if I have seven or so vars and several subs or funcs need to mess
with
> them variously are there overhead considerations like passing args uses
more
> memory than storing vars in module scope or???
> or speed of execution? or ease of writing? or ease of understanding code?
> I've read that 'global' variables as bad and in a way I guess I've thought
> that module level was kind of 'global' but it seems that in vba since
> there's different levels of scope available that it's not totally
> unacceptable to have a variable other than inside a proceedure and,
> therefore, to have to pass any values around as arguments and return
values.
> Or maybe I'm totally misunderstanding all this scope stuff and global
> variables being a bad thing???
> any suggestions?
> Thanks
> Mark
>
>

[Anonymous]

Frank,
Thanks much for the tip. I'd be very interested to hear a little
elaboration on that 'control access' idea.
I'm also now thinking that by putting them as args it makes the proceedure
more portable to other project that may use a totally different var name,
where, in contrast, referring to a module level var of some name, i'd have
to rewrite it some to use in other projects.
And another clarification: in this context does 'global' mean 'project
level'?
ie at the top of some module, before any sub() or function() i declare a var
like:
Public arThisArray as Variant, then any proceedure in the project has access
to that var...is this what is meant by 'global'?
I've also heard something about other projects 'referring(maybe wrong term)'
to another projects subs or vars...I don't quite get this yet. ...back to
f1. If that's the case, should a var name have the name of it's project or
other tweak to keep them straight? like arThisArrayPrj1???
Thanks as always for any edification,
Mark
"Frank Oquendo" wrote in message
news:A36A77B31F4F966BF95860FDBD7F8441@in.WebX.maYIadrTaRb...
> I prefer to pass arguments to functions. Doing so allows me to control
> access to a given variable which makes it easier to track down bugs.

[Anonymous]

Mark:
I've heard folks say that global variables are not a great idea, and here's
the thinking, from what I understand. The main reason to try to avoid using
global variables is they are an invitation for hard to find buggies. You must be
sure when your app goes to use that variable, that nothing else has
inadvertently changed the data. Passing the data as an argument insures the sub
or function gets the right data. Furthermore, if many subs or functions use the
variable, passing the data as an argument makes the code more maintainable,
since if the way a global is used in one place is changed, you must then check
every other use of the global in the whole project. That's the thinking. I tend
to agree, (not quite wholeheartedly, but it does make sense) but if you are
crafty, you can usually avoid using globals anyhow.
Module level variables on the other hand, I feel, are a fact of life. For
instance, manipulating AutoCad in VB, you may need many functions and subs that
require a reference to the application object, or the active doc object. No
sense in reinventing the wheel over and over. I tend to only use then for things
of this nature though. And grouping cad tools in a module together, breaking the
app into smaller more portable chunks, helps me understand what I'm doing
better. It takes a little longer to make the chunks reusable, but building a
module library of code makes your hard work go further. The little bits may be
strung together in endless variations as need arises. Wrap a bunch of common
stuff up in a dll and your one better. Once it works, it's tucked away. VB is a
module language. It's made to rapidly develop complex applications using
pre-made chunks.

Andy

Mark Propst wrote:

> Frank,
> Thanks much for the tip. I'd be very interested to hear a little
> elaboration on that 'control access' idea.
> I'm also now thinking that by putting them as args it makes the proceedure
> more portable to other project that may use a totally different var name,
> where, in contrast, referring to a module level var of some name, i'd have
> to rewrite it some to use in other projects.
> And another clarification: in this context does 'global' mean 'project
> level'?
> ie at the top of some module, before any sub() or function() i declare a var
> like:
> Public arThisArray as Variant, then any proceedure in the project has access
> to that var...is this what is meant by 'global'?
> I've also heard something about other projects 'referring(maybe wrong term)'
> to another projects subs or vars...I don't quite get this yet. ...back to
> f1. If that's the case, should a var name have the name of it's project or
> other tweak to keep them straight? like arThisArrayPrj1???
> Thanks as always for any edification,
> Mark
> "Frank Oquendo" wrote in message
> news:A36A77B31F4F966BF95860FDBD7F8441@in.WebX.maYIadrTaRb...
> > I prefer to pass arguments to functions. Doing so allows me to control
> > access to a given variable which makes it easier to track down bugs.

[Anonymous]

Mark:


> And another clarification: in this context does 'global' mean 'project
> level'?

a global variable is indeed a 'project level (scope) variable

> ie at the top of some module, before any sub() or function() i declare a var
> like:
> Public arThisArray as Variant, then any proceedure in the project has access
> to that var...is this what is meant by 'global'?

no, that would be a module level (scope) variable

> I've also heard something about other projects 'referring(maybe wrong term)'
> to another projects subs or vars...I don't quite get this yet. ...back to
> f1.

If I'm not wrong, I believe the only way a project may use another project's
subs or functions is by setting a reference to them in the references for that
project. But one module may use another module's Public subs and functions in
the same project by including the module's name before the sub or function
name. module1.somefunction

[Anonymous]

> > ie at the top of some module, before any sub() or function() i declare a var
> > like:
> > Public arThisArray as Variant, then any proceedure in the project has access
> > to that var...is this what is meant by 'global'?
>
> no, that would be a module level (scope) variable

any procedure in that module may use it.
A global is placed at the top of a module as well, but the var is expressly
declared as global. Like dim or private or public, global is a dimensioning
statement.
As state in the other post, A public (module level) var may be accessed by another
module by placing the module's name first module1.somePublicvar

[Anonymous]

Hi again Andy!
Thanks for that explanation. Really helps to hear it spelled out.
I'm just slow that way.
So the only difference between a global and a module level is that you have
to put the "modulename." in front of the proc or var name?
so
...Module1
Global ThisVar as Integer
Public ThisStr as String

Sub ThisSub ()
Dim ThatVar as Integer
ThatVar = ThisVar +1
ThisStr = "I think I can"
End sub
...Module2
sub OtherSub ()
Dim anotherVar as Integer
Dim anotherStr as String
anotherVar = thisVar + 10
anotherStr = ThisSub.ThisStr & vbCr & "I'm sure I can"
MsgBox anotherStr
End Sub

So functionally a module level and a global level are the same thing, only
you type one a little differently????? Am I missing a deeper meaning here?

> > > to that var...is this what is meant by 'global'?
> >
> > no, that would be a module level (scope) variable
>Like dim or private or public, global is a dimensioning
> statement.
WOW I've never heard or seen that anywhere! Where have I been?
vb help under global on the search tab says
"To enter module-level declarations, go to the Declarations section of a
module. To enter global declarations, go to the Declarations section of a
module and use the Public statement for constants and variables. You can
also use the Dim, Static, and Private keywords to make declarations."

> As state in the other post, A public (module level) var may be accessed by
another
> module by placing the module's name first module1.somePublicvar
Hey, I'm hammerin away at that dictionary thing, thanks to the head start
you gave me. That stuff is the greatest - me slow on uptake - how's yer
proj comin?
Mark

[Anonymous]

If you've got the patience, try making a class or two for your variables.
Then you can put all your variables into the class and pass that object as
your argument btwn. functions/subs. It's good practice to start with simple,
small classes. Each object you create will stick around till you destroy it,
which is almost as good (sometimes better than) a public variable. The more
you find out about classes, the more you will like them 🙂

clm

"Frank Oquendo" wrote in message
news:A36A77B31F4F966BF95860FDBD7F8441@in.WebX.maYIadrTaRb...
> I prefer to pass arguments to functions. Doing so allows me to control
> access to a given variable which makes it easier to track down bugs.
>
> --
> Good judgment comes from experience.
> Experience comes from bad judgment.
>
> http://www.acadx.com
>
>
> "MP" wrote in message
> news:789CE53E17E23FCF894625EBD49CB69B@in.WebX.maYIadrTaRb...
> > Hi,
> > Is there a rule of thumb to decide whether to declare variables at
module
> > scope so all proceedures in that module can use them or whether to write
> all
> > proceedures to accept args and pass the vars around that way?
> > Like if I have seven or so vars and several subs or funcs need to mess
> with
> > them variously are there overhead considerations like passing args uses
> more
> > memory than storing vars in module scope or???
> > or speed of execution? or ease of writing? or ease of understanding
code?
> > I've read that 'global' variables as bad and in a way I guess I've
thought
> > that module level was kind of 'global' but it seems that in vba since
> > there's different levels of scope available that it's not totally
> > unacceptable to have a variable other than inside a proceedure and,
> > therefore, to have to pass any values around as arguments and return
> values.
> > Or maybe I'm totally misunderstanding all this scope stuff and global
> > variables being a bad thing???
> > any suggestions?
> > Thanks
> > Mark
> >
> >
>
>

[Anonymous]

Chris,
Yeah, I need to figure that class thing out next. I've been reading and
reading about them and trying to figure out how to turn my needs into
classes I just haven't dove in and got my feet wet yet.
...fear...no...i..i..i ain't afraid of classes....no...not m..m...me....
I've been stuck for months on turning things into classes cause I don't know
how to start small and build up bit by bit - I keep thinking I have to
derive my big class first - that holds all objects routines vars etc for
every function I want to eventually incorporate - and then make each
subentity a class below the big class etc...maybe I don't have to do that -
It just seemed like I should be figuring out the 'big' picture first so
everything would be organized around the central principle and that's so
monumental I can't get it all in my head at one time...
at this point I just have reams of flowcharts and organizational ideas of
how things would be but I cant' seem to get started actually building a
class.
I'm stuck in the mind set of do this function now to solve this particular
problem or speed up this process. rather than build a class that would have
multiple functions(properties,methods)to do all the different jobs I need to
do at different times with my whatever object (building)
oh well, some day...if i live that long!

Thanks for the suggestion though, I really need to keep moving in that
direction...
Mark

"Chris McChristian" wrote in message
news:9D95BE7DE47770529DE52D2D55440705@in.WebX.maYIadrTaRb...
> If you've got the patience, try making a class or two for your variables.

[Anonymous]

Hi Andy,

Earlier on in this discusion Frank made a convincing (to me) point about
Global variables being hard to track.
Use of this
> As state in the other post, A public (module level) var may be accessed by
another
> module by placing the module's name first module1.somePublicvar
technique of using the variable outside its nominal scope seems to me to be
much more risky as one may not expect to have to check the varaible outside
of its nominal scope.

Would you recommend purely reading it or both reading and changing it ?

--




Laurie Comerford
CADApps
www.cadapps.com.au

"Andy & Starr" wrote in message
news:3C3A58DD.555E488E@bellsouth.net...
> > > ie at the top of some module, before any sub() or function() i declare
a var
> > > like:
> > > Public arThisArray as Variant, then any proceedure in the project has
access
> > > to that var...is this what is meant by 'global'?
> >
> > no, that would be a module level (scope) variable
>
> any procedure in that module may use it.
> A global is placed at the top of a module as well, but the var is
expressly
> declared as global. Like dim or private or public, global is a
dimensioning
> statement.
> As state in the other post, A public (module level) var may be accessed by
another
> module by placing the module's name first module1.somePublicvar
>

[Anonymous]

LOL.
You sound just like me!
I was too fearful of the classes to touch on them, so i created these huge
dynamic variant arrays.
I used many public constants to build an index of the arrays variables,
initialization functions, add and remove functions... Any time i added
another "widget", i also added all its properites to my array, and if i
needed to record another property for each "widget," the entire array grew
even larger....until it became unmanagable....when what i really needed was
a Collection Class of Widget objects....
The main thing is to start small. You can't roll the entire project up into
a single class without having some experience with classes first. Make a
Point class. Add to it
Public X as Double
Public Y as Double
;;;Then add the line to your main:
Dim oPtOne as New Point
Set oPtOne.X = 0.0
Set oPtOne.Y= 0.0
;;;Simple, no? Add to your class:
Public Name as variant
Now you can have a name for it. Then add a Public Z as Double, and you've
got the basics. Worry about the Let/Get statements after you've played with
it a little bit. Using Globals in your class is the cheap way to go about
it, but you can change that when you're ready 🙂 The next thing to try is
adding a method to your class to list it's X, Y, and Z properties as a
single array. Just add to the class:
Function ListPts () As Variant
ReDim ListPts (0 to 2)
ListPts(0)= X
ListPts(1)=Y
ListPts(2)=Z
End Function
;;;Then you can call it from your main:
AnyVariant = oPtOne.ListPts
Then you can throw other things in, like a bolt class, w/ vars for nominal
diameter, pitch, length, etc. You'll be much happier with your code once you
get it going.
I used several resources to conquer my fear of classes, maybe one of them
will help you do the same. Here's just a few to look into:
(found this one lying around collecting dust next to some 5 year old
Grainger cataloges)
Advanced Microsoft Visual Basic 5: Chapter 5 "Changing Your Approach to
Visual Basic Coding"
http://www.acadx.com/articles/006.htm (good example of what you could do
w/classes)
Visual Basic 6.0 Programmers Guide: Chapter 9 "Programming With Objects"


"Mark Propst" wrote in message
news:CC16F92534D79D522FC85835E88F0A85@in.WebX.maYIadrTaRb...
> Chris,
> Yeah, I need to figure that class thing out next. I've been reading and
> reading about them and trying to figure out how to turn my needs into
> classes I just haven't dove in and got my feet wet yet.
> ...fear...no...i..i..i ain't afraid of classes....no...not m..m...me....
> I've been stuck for months on turning things into classes cause I don't
know
> how to start small and build up bit by bit - I keep thinking I have to
> derive my big class first - that holds all objects routines vars etc for
> every function I want to eventually incorporate - and then make each
> subentity a class below the big class etc...maybe I don't have to do
that -
> It just seemed like I should be figuring out the 'big' picture first so
> everything would be organized around the central principle and that's so
> monumental I can't get it all in my head at one time...
> at this point I just have reams of flowcharts and organizational ideas of
> how things would be but I cant' seem to get started actually building a
> class.
> I'm stuck in the mind set of do this function now to solve this particular
> problem or speed up this process. rather than build a class that would
have
> multiple functions(properties,methods)to do all the different jobs I need
to
> do at different times with my whatever object (building)
> oh well, some day...if i live that long!
>
> Thanks for the suggestion though, I really need to keep moving in that
> direction...
> Mark
>
> "Chris McChristian" wrote in message
> news:9D95BE7DE47770529DE52D2D55440705@in.WebX.maYIadrTaRb...
> > If you've got the patience, try making a class or two for your
variables.
>
>
>

[Anonymous]

Great point! it is in fact a global variable for all intent purposes, and
subject to goof ups. I never really access variables from other modules that
way much at all in practice. Just felt remiss if I hadn't mentioned it.
Sometimes it seems like some code ends up in a form event or something and that
would probably be in read only mode. In other words say to populate a dialog box
or something of that nature. But I do call module's public subs and functions.
In fact doing so seems to be useful for being able to break the project into
smaller more manageable parts.
But it seems as the project matures, you end up grouping similar routines in
modules together, and each bit does it's own thing with out needing to get at
the other module's stuff.

Laurie Comerford wrote:

> Hi Andy,
>
> Earlier on in this discusion Frank made a convincing (to me) point about
> Global variables being hard to track.
> Use of this
> > As state in the other post, A public (module level) var may be accessed by
> another
> > module by placing the module's name first module1.somePublicvar
> technique of using the variable outside its nominal scope seems to me to be
> much more risky as one may not expect to have to check the varaible outside
> of its nominal scope.
>
> Would you recommend purely reading it or both reading and changing it ?
>
> --
>
> Laurie Comerford
> CADApps
> www.cadapps.com.au
>
> "Andy & Starr" wrote in message
> news:3C3A58DD.555E488E@bellsouth.net...
> > > > ie at the top of some module, before any sub() or function() i declare
> a var
> > > > like:
> > > > Public arThisArray as Variant, then any proceedure in the project has
> access
> > > > to that var...is this what is meant by 'global'?
> > >
> > > no, that would be a module level (scope) variable
> >
> > any procedure in that module may use it.
> > A global is placed at the top of a module as well, but the var is
> expressly
> > declared as global. Like dim or private or public, global is a
> dimensioning
> > statement.
> > As state in the other post, A public (module level) var may be accessed by
> another
> > module by placing the module's name first module1.somePublicvar
> >

[Anonymous]

> The more
> you find out about classes, the more you will like them 🙂

Chris:
I agree. It's easy, and powerful. And as you state in your later post you start
small, get it working and build from their. I went the dynamic array route as
well. It was slow and terribly complex. Writing classes takes a little bit of
shift in thinking but once you grasp the idea it's easy. I used the class
building utility in VB to help learn the basics and get me started.

[Anonymous]

Oh Man, Ya got me goin now dude>
I gotta do it.
Thanks for the nudge. Nice simple examples, and Franks' page too, starting
to gel....
I can see a faint glimmer on the horizon....is it coming this way???
Thanks,
Mark

Chris McChristian wrote in message
> LOL.

> Then you can throw other things in, like a bolt class, w/ vars for nominal
> diameter, pitch, length, etc.

yeah, cool.

come ta poppa lil classes...