Declarations variables, Dim, some guidance please

[Neal Zimm]

In an application that I'm developing I have dim'd quite a few variables in
Declarations. I'll admit some of it is not wanting to take the time to put
those vars that are used quite often in many macros within the sub
SubName(var list) parenthesis.

1) What advice can you offer on the pro's and cons of this technique? All of
the application's code is in ONE module.

2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
integer in Declarations, had a good value > 0 in prior macros, but was 0 in
the macro I was testing.

Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
NOT get a duplicate Dim error?

Thanks.
--
Neal Z

[JE McGimpsey]

By preference (and it's *mostly* preference), I try to declare only
procedure arguments and local (procedure-level) variables. This is
especially useful in large applications where one may not be sure that a
global/module-level variable isn't changed by an unrelated procedure.

You didn't get a duplicate Dim error because one variable was declared
at the module level, and one was declared within the sub. Local
variables always override global variables within their own procedure.
This is actually an advantage, as one can re-use variable names within
multiple procedures, but each procedure sees only its own, local
variable. For instance, note the reuse of "i" in:

Public Sub Sub1()
Dim i As Long
For i = 1 To 10
Sub2 "Iteration " & i & ": "
Next i
End Sub

Public Sub Sub2(ByVal sStr As String)
Dim i As Long
For i = 1 To 3
Debug.Print sStr & i
Next i
End Sub

If your code is fairly small, and will never be maintained by anyone
else, using module-level variables is probably fine, as long as you keep
track of which procedures are modifying them, and when.

If you're writing code that will be maintained by others, I'd strongly
recommend using local variables as much as possible.



In article <[email protected]>,
Neal Zimm <[email protected]> wrote:

> In an application that I'm developing I have dim'd quite a few variables in
> Declarations. I'll admit some of it is not wanting to take the time to put
> those vars that are used quite often in many macros within the sub
> SubName(var list) parenthesis.
>
> 1) What advice can you offer on the pro's and cons of this technique? All of
> the application's code is in ONE module.
>
> 2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
> integer in Declarations, had a good value > 0 in prior macros, but was 0 in
> the macro I was testing.
>
> Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
> macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
> NOT get a duplicate Dim error?

[Jake Marx]

Ni Neal,

Neal Zimm wrote:
> In an application that I'm developing I have dim'd quite a few
> variables in Declarations. I'll admit some of it is not wanting to
> take the time to put those vars that are used quite often in many
> macros within the sub SubName(var list) parenthesis.
>
> 1) What advice can you offer on the pro's and cons of this technique?
> All of the application's code is in ONE module.

I don't like to declare variables at module level or globally (Public
keyword in standard module) unless I have to. Some reasons are readability,
ease of maintenance, and knowing your variables won't be "trounced upon" by
various procedures. Module-level and global variables will also use more
resources.

The alternative is to pass variables via arguments to functions/subroutines.
It is undoubtedly more work upfront, but IMO it pays off to do it this way.

> 2) I got 'bitten' when testing a macro where a var called Draw was
> dim'd as integer in Declarations, had a good value > 0 in prior
> macros, but was 0 in the macro I was testing.
>
> Sure enough, I had dim'd it again, inadvertantly, also as Integer
> in the macro being tested. Hence the 0 value, I guess. The QUESTION
> is, why did I NOT get a duplicate Dim error?

Well, since the variables had different scopes, it wasn't a duplicate
declaration. You had one module-level variable named Draw, and you had a
local variable named Draw with a completely different value.

--
Regards,

Jake Marx
MS MVP - Excel
www.longhead.com

[please keep replies in the newsgroup - email address unmonitored]

[Bob Phillips]

"Neal Zimm" <[email protected]> wrote in message
news:[email protected]...
> In an application that I'm developing I have dim'd quite a few variables
in
> Declarations. I'll admit some of it is not wanting to take the time to put
> those vars that are used quite often in many macros within the sub
> SubName(var list) parenthesis.
>
> 1) What advice can you offer on the pro's and cons of this technique? All
of
> the application's code is in ONE module.

Personally, I try and keep this to a minimum, as it is always possible that
in a procedure the variable will have a residual value from a previous
procedure, preferring to use arguments. Yes, I know we should always
initialise, but it is too easy to be lazy and rely on the default initial
value.

The pros and the cons are the same things really, they keep the value across
procedures, they have (at least) module scope, and so on, it would depend
upon the application as to whether that is a pro or a con. What I am saying
I guess is that each variablke should be carefully considerred before either
placing in Declarations or a procedure.

> 2) I got 'bitten' when testing a macro where a var called Draw was dim'd
as
> integer in Declarations, had a good value > 0 in prior macros, but was 0
in
> the macro I was testing.
>
> Sure enough, I had dim'd it again, inadvertantly, also as Integer in
the
> macro being tested. Hence the 0 value, I guess. The QUESTION is, why did
I
> NOT get a duplicate Dim error?

Because it is not a duplicate. The first was a module scope variable, the
second was a procedure scope variable, it is quite legitimate to have both.
When you do, when in the procedure with the procedure scope variable will
be the one used, as you experienced.

[STEVE BELL]

Bob,

Back when I was starting with VBE (xl97) it seemed that double declarations
of a variable
such as Public x as Long (in the project) and Dim x as Long (in a module)
would sometimes cause Excel to crash.

Was I jumping to conclusions and it was really something else causing the
crash, or was that a problem with xl97?

--
steveB

Remove "AYN" from email to respond
"Bob Phillips" <[email protected]> wrote in message
news:[email protected]...
> "Neal Zimm" <[email protected]> wrote in message
> news:[email protected]...
>> In an application that I'm developing I have dim'd quite a few variables
> in
>> Declarations. I'll admit some of it is not wanting to take the time to
>> put
>> those vars that are used quite often in many macros within the sub
>> SubName(var list) parenthesis.
>>
>> 1) What advice can you offer on the pro's and cons of this technique? All
> of
>> the application's code is in ONE module.
>
> Personally, I try and keep this to a minimum, as it is always possible
> that
> in a procedure the variable will have a residual value from a previous
> procedure, preferring to use arguments. Yes, I know we should always
> initialise, but it is too easy to be lazy and rely on the default initial
> value.
>
> The pros and the cons are the same things really, they keep the value
> across
> procedures, they have (at least) module scope, and so on, it would depend
> upon the application as to whether that is a pro or a con. What I am
> saying
> I guess is that each variablke should be carefully considerred before
> either
> placing in Declarations or a procedure.
>
>> 2) I got 'bitten' when testing a macro where a var called Draw was dim'd
> as
>> integer in Declarations, had a good value > 0 in prior macros, but was 0
> in
>> the macro I was testing.
>>
>> Sure enough, I had dim'd it again, inadvertantly, also as Integer in
> the
>> macro being tested. Hence the 0 value, I guess. The QUESTION is, why
>> did
> I
>> NOT get a duplicate Dim error?
>
> Because it is not a duplicate. The first was a module scope variable, the
> second was a procedure scope variable, it is quite legitimate to have
> both.
> When you do, when in the procedure with the procedure scope variable will
> be the one used, as you experienced.
>
>

[Jim Thomlinson]

Good coding practice is to use global or module level variable declarations
as little as possible. The big reason is that it makes the code very
difficult to debug. At any given time it can be difficult to know the value
of a variable because all procedures can access it. One small change to one
procedure can have side effects on all of the procedures that access that
variable. The problem is that when you make the change it is not at all
obvious what all of the consequences are. If you are passing the variable
then it is reasonalby obvious. The only reasons that I ever use Globals are:

1. I need a value determined at run time to persist. An example might be a
password to log into some subsystems. I get the user to enter it once and
that value is stored for as long as the program runs. Any time I need to log
into the subsystem I just call up the value. I don't have to worry about who
changed the value last becuase it is only set once at the beginning of
exectuion.

2. I have a function or sub procedure that is called repeatedly (great for
recursion). In order to speed up the exectution I will have it use global
variables so that the variables do not need to be created and destroyed each
time the procedure is called.
--
HTH...

Jim Thomlinson


"Neal Zimm" wrote:

> In an application that I'm developing I have dim'd quite a few variables in
> Declarations. I'll admit some of it is not wanting to take the time to put
> those vars that are used quite often in many macros within the sub
> SubName(var list) parenthesis.
>
> 1) What advice can you offer on the pro's and cons of this technique? All of
> the application's code is in ONE module.
>
> 2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
> integer in Declarations, had a good value > 0 in prior macros, but was 0 in
> the macro I was testing.
>
> Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
> macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
> NOT get a duplicate Dim error?
>
> Thanks.
> --
> Neal Z

[Bob Phillips]

Steve,

I can't say you were jumping to conclusions, but I must admit to never had
that experience myself. Excel has crashed on me a few times <g>, but it was
usually attributable to me wrongly using APIs, or having a virus.

--

HTH

RP
(remove nothere from the email address if mailing direct)


"STEVE BELL" <[email protected]> wrote in message
news:_%9Me.2938$Y55.855@trnddc06...
> Bob,
>
> Back when I was starting with VBE (xl97) it seemed that double
declarations
> of a variable
> such as Public x as Long (in the project) and Dim x as Long (in a module)
> would sometimes cause Excel to crash.
>
> Was I jumping to conclusions and it was really something else causing the
> crash, or was that a problem with xl97?
>
> --
> steveB
>
> Remove "AYN" from email to respond
> "Bob Phillips" <[email protected]> wrote in message
> news:[email protected]...
> > "Neal Zimm" <[email protected]> wrote in message
> > news:[email protected]...
> >> In an application that I'm developing I have dim'd quite a few
variables
> > in
> >> Declarations. I'll admit some of it is not wanting to take the time to
> >> put
> >> those vars that are used quite often in many macros within the sub
> >> SubName(var list) parenthesis.
> >>
> >> 1) What advice can you offer on the pro's and cons of this technique?
All
> > of
> >> the application's code is in ONE module.
> >
> > Personally, I try and keep this to a minimum, as it is always possible
> > that
> > in a procedure the variable will have a residual value from a previous
> > procedure, preferring to use arguments. Yes, I know we should always
> > initialise, but it is too easy to be lazy and rely on the default
initial
> > value.
> >
> > The pros and the cons are the same things really, they keep the value
> > across
> > procedures, they have (at least) module scope, and so on, it would
depend
> > upon the application as to whether that is a pro or a con. What I am
> > saying
> > I guess is that each variablke should be carefully considerred before
> > either
> > placing in Declarations or a procedure.
> >
> >> 2) I got 'bitten' when testing a macro where a var called Draw was
dim'd
> > as
> >> integer in Declarations, had a good value > 0 in prior macros, but was
0
> > in
> >> the macro I was testing.
> >>
> >> Sure enough, I had dim'd it again, inadvertantly, also as Integer in
> > the
> >> macro being tested. Hence the 0 value, I guess. The QUESTION is, why
> >> did
> > I
> >> NOT get a duplicate Dim error?
> >
> > Because it is not a duplicate. The first was a module scope variable,
the
> > second was a procedure scope variable, it is quite legitimate to have
> > both.
> > When you do, when in the procedure with the procedure scope variable
will
> > be the one used, as you experienced.
> >
> >
>
>

[Dave Peterson]

How about if you're picking up tons of values from a worksheet(s) that are used
in lots of different subroutines.

I've used an initialization routine that returns all those values into global
variables.

Jim Thomlinson wrote:
>
> Good coding practice is to use global or module level variable declarations
> as little as possible. The big reason is that it makes the code very
> difficult to debug. At any given time it can be difficult to know the value
> of a variable because all procedures can access it. One small change to one
> procedure can have side effects on all of the procedures that access that
> variable. The problem is that when you make the change it is not at all
> obvious what all of the consequences are. If you are passing the variable
> then it is reasonalby obvious. The only reasons that I ever use Globals are:
>
> 1. I need a value determined at run time to persist. An example might be a
> password to log into some subsystems. I get the user to enter it once and
> that value is stored for as long as the program runs. Any time I need to log
> into the subsystem I just call up the value. I don't have to worry about who
> changed the value last becuase it is only set once at the beginning of
> exectuion.
>
> 2. I have a function or sub procedure that is called repeatedly (great for
> recursion). In order to speed up the exectution I will have it use global
> variables so that the variables do not need to be created and destroyed each
> time the procedure is called.
> --
> HTH...
>
> Jim Thomlinson
>
> "Neal Zimm" wrote:
>
> > In an application that I'm developing I have dim'd quite a few variables in
> > Declarations. I'll admit some of it is not wanting to take the time to put
> > those vars that are used quite often in many macros within the sub
> > SubName(var list) parenthesis.
> >
> > 1) What advice can you offer on the pro's and cons of this technique? All of
> > the application's code is in ONE module.
> >
> > 2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
> > integer in Declarations, had a good value > 0 in prior macros, but was 0 in
> > the macro I was testing.
> >
> > Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
> > macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
> > NOT get a duplicate Dim error?
> >
> > Thanks.
> > --
> > Neal Z

--

Dave Peterson

[Bob Phillips]

Use a class with properties, or maybe a collection class.

--

HTH

RP
(remove nothere from the email address if mailing direct)


"Dave Peterson" <[email protected]> wrote in message
news:[email protected]...
> How about if you're picking up tons of values from a worksheet(s) that are
used
> in lots of different subroutines.
>
> I've used an initialization routine that returns all those values into
global
> variables.
>
> Jim Thomlinson wrote:
> >
> > Good coding practice is to use global or module level variable
declarations
> > as little as possible. The big reason is that it makes the code very
> > difficult to debug. At any given time it can be difficult to know the
value
> > of a variable because all procedures can access it. One small change to
one
> > procedure can have side effects on all of the procedures that access
that
> > variable. The problem is that when you make the change it is not at all
> > obvious what all of the consequences are. If you are passing the
variable
> > then it is reasonalby obvious. The only reasons that I ever use Globals
are:
> >
> > 1. I need a value determined at run time to persist. An example might be
a
> > password to log into some subsystems. I get the user to enter it once
and
> > that value is stored for as long as the program runs. Any time I need to
log
> > into the subsystem I just call up the value. I don't have to worry about
who
> > changed the value last becuase it is only set once at the beginning of
> > exectuion.
> >
> > 2. I have a function or sub procedure that is called repeatedly (great
for
> > recursion). In order to speed up the exectution I will have it use
global
> > variables so that the variables do not need to be created and destroyed
each
> > time the procedure is called.
> > --
> > HTH...
> >
> > Jim Thomlinson
> >
> > "Neal Zimm" wrote:
> >
> > > In an application that I'm developing I have dim'd quite a few
variables in
> > > Declarations. I'll admit some of it is not wanting to take the time to
put
> > > those vars that are used quite often in many macros within the sub
> > > SubName(var list) parenthesis.
> > >
> > > 1) What advice can you offer on the pro's and cons of this technique?
All of
> > > the application's code is in ONE module.
> > >
> > > 2) I got 'bitten' when testing a macro where a var called Draw was
dim'd as
> > > integer in Declarations, had a good value > 0 in prior macros, but was
0 in
> > > the macro I was testing.
> > >
> > > Sure enough, I had dim'd it again, inadvertantly, also as Integer
in the
> > > macro being tested. Hence the 0 value, I guess. The QUESTION is, why
did I
> > > NOT get a duplicate Dim error?
> > >
> > > Thanks.
> > > --
> > > Neal Z
>
> --
>
> Dave Peterson

[STEVE BELL]

Bob,

The only thing else to add is that thanks to this group and some
experimenting with code - I did find many things in code that would crash
Excel. Since cleaning up "those" issues - I can't remember the last time my
code caused a crash.

I will continue to caution about declaring the same variable in and out of a
module.

Thanks for your input. And Dave's, and "Hi Every one else".

--
steveB

Remove "AYN" from email to respond
"Bob Phillips" <[email protected]> wrote in message
news:[email protected]...
> Steve,
>
> I can't say you were jumping to conclusions, but I must admit to never had
> that experience myself. Excel has crashed on me a few times <g>, but it
> was
> usually attributable to me wrongly using APIs, or having a virus.
>
> --
>
> HTH
>
> RP
> (remove nothere from the email address if mailing direct)
>
>
> "STEVE BELL" <[email protected]> wrote in message
> news:_%9Me.2938$Y55.855@trnddc06...
>> Bob,
>>
>> Back when I was starting with VBE (xl97) it seemed that double
> declarations
>> of a variable
>> such as Public x as Long (in the project) and Dim x as Long (in a module)
>> would sometimes cause Excel to crash.
>>
>> Was I jumping to conclusions and it was really something else causing the
>> crash, or was that a problem with xl97?
>>
>> --
>> steveB
>>
>> Remove "AYN" from email to respond
>> "Bob Phillips" <[email protected]> wrote in message
>> news:[email protected]...
>> > "Neal Zimm" <[email protected]> wrote in message
>> > news:[email protected]...
>> >> In an application that I'm developing I have dim'd quite a few
> variables
>> > in
>> >> Declarations. I'll admit some of it is not wanting to take the time to
>> >> put
>> >> those vars that are used quite often in many macros within the sub
>> >> SubName(var list) parenthesis.
>> >>
>> >> 1) What advice can you offer on the pro's and cons of this technique?
> All
>> > of
>> >> the application's code is in ONE module.
>> >
>> > Personally, I try and keep this to a minimum, as it is always possible
>> > that
>> > in a procedure the variable will have a residual value from a previous
>> > procedure, preferring to use arguments. Yes, I know we should always
>> > initialise, but it is too easy to be lazy and rely on the default
> initial
>> > value.
>> >
>> > The pros and the cons are the same things really, they keep the value
>> > across
>> > procedures, they have (at least) module scope, and so on, it would
> depend
>> > upon the application as to whether that is a pro or a con. What I am
>> > saying
>> > I guess is that each variablke should be carefully considerred before
>> > either
>> > placing in Declarations or a procedure.
>> >
>> >> 2) I got 'bitten' when testing a macro where a var called Draw was
> dim'd
>> > as
>> >> integer in Declarations, had a good value > 0 in prior macros, but was
> 0
>> > in
>> >> the macro I was testing.
>> >>
>> >> Sure enough, I had dim'd it again, inadvertantly, also as Integer
>> >> in
>> > the
>> >> macro being tested. Hence the 0 value, I guess. The QUESTION is, why
>> >> did
>> > I
>> >> NOT get a duplicate Dim error?
>> >
>> > Because it is not a duplicate. The first was a module scope variable,
> the
>> > second was a procedure scope variable, it is quite legitimate to have
>> > both.
>> > When you do, when in the procedure with the procedure scope variable
> will
>> > be the one used, as you experienced.
>> >
>> >
>>
>>
>
>

[Neal Zimm]

Thanks to all for the sound advice, I hope y'all don't mind a common response.
I'm relatively new to the VB game, self taught (with help from this bulletin
board)
, and there's LOTS I don't know. (see later re: class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." & vbcr
' used in inputbox dialogs


2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

Again,
Thanks to all. Your help is very much appreciated.
Neal Z.
--
Neal Z


"Jim Thomlinson" wrote:

> Good coding practice is to use global or module level variable declarations
> as little as possible. The big reason is that it makes the code very
> difficult to debug. At any given time it can be difficult to know the value
> of a variable because all procedures can access it. One small change to one
> procedure can have side effects on all of the procedures that access that
> variable. The problem is that when you make the change it is not at all
> obvious what all of the consequences are. If you are passing the variable
> then it is reasonalby obvious. The only reasons that I ever use Globals are:
>
> 1. I need a value determined at run time to persist. An example might be a
> password to log into some subsystems. I get the user to enter it once and
> that value is stored for as long as the program runs. Any time I need to log
> into the subsystem I just call up the value. I don't have to worry about who
> changed the value last becuase it is only set once at the beginning of
> exectuion.
>
> 2. I have a function or sub procedure that is called repeatedly (great for
> recursion). In order to speed up the exectution I will have it use global
> variables so that the variables do not need to be created and destroyed each
> time the procedure is called.
> --
> HTH...
>
> Jim Thomlinson
>
>
> "Neal Zimm" wrote:
>
> > In an application that I'm developing I have dim'd quite a few variables in
> > Declarations. I'll admit some of it is not wanting to take the time to put
> > those vars that are used quite often in many macros within the sub
> > SubName(var list) parenthesis.
> >
> > 1) What advice can you offer on the pro's and cons of this technique? All of
> > the application's code is in ONE module.
> >
> > 2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
> > integer in Declarations, had a good value > 0 in prior macros, but was 0 in
> > the macro I was testing.
> >
> > Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
> > macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
> > NOT get a duplicate Dim error?
> >
> > Thanks.
> > --
> > Neal Z

[Neal Zimm]

Thanks to all for the sound advice, I hope y'all don't mind a common response.
I'm relatively new to the VB game, self taught (with help from this bulletin
board)
, and there's LOTS I don't know. (see later re: class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." & vbcr
' used in inputbox dialogs


2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

Again,
Thanks to all. Your help is very much appreciated.
Neal Z.
--
Neal Z


"JE McGimpsey" wrote:

> By preference (and it's *mostly* preference), I try to declare only
> procedure arguments and local (procedure-level) variables. This is
> especially useful in large applications where one may not be sure that a
> global/module-level variable isn't changed by an unrelated procedure.
>
> You didn't get a duplicate Dim error because one variable was declared
> at the module level, and one was declared within the sub. Local
> variables always override global variables within their own procedure.
> This is actually an advantage, as one can re-use variable names within
> multiple procedures, but each procedure sees only its own, local
> variable. For instance, note the reuse of "i" in:
>
> Public Sub Sub1()
> Dim i As Long
> For i = 1 To 10
> Sub2 "Iteration " & i & ": "
> Next i
> End Sub
>
> Public Sub Sub2(ByVal sStr As String)
> Dim i As Long
> For i = 1 To 3
> Debug.Print sStr & i
> Next i
> End Sub
>
> If your code is fairly small, and will never be maintained by anyone
> else, using module-level variables is probably fine, as long as you keep
> track of which procedures are modifying them, and when.
>
> If you're writing code that will be maintained by others, I'd strongly
> recommend using local variables as much as possible.
>
>
>
> In article <[email protected]>,
> Neal Zimm <[email protected]> wrote:
>
> > In an application that I'm developing I have dim'd quite a few variables in
> > Declarations. I'll admit some of it is not wanting to take the time to put
> > those vars that are used quite often in many macros within the sub
> > SubName(var list) parenthesis.
> >
> > 1) What advice can you offer on the pro's and cons of this technique? All of
> > the application's code is in ONE module.
> >
> > 2) I got 'bitten' when testing a macro where a var called Draw was dim'd as
> > integer in Declarations, had a good value > 0 in prior macros, but was 0 in
> > the macro I was testing.
> >
> > Sure enough, I had dim'd it again, inadvertantly, also as Integer in the
> > macro being tested. Hence the 0 value, I guess. The QUESTION is, why did I
> > NOT get a duplicate Dim error?
>

[Neal Zimm]

Thanks to all for the sound advice, I hope y'all don't mind a common response.
I'm relatively new to the VB game, self taught (with help from this bulletin
board)
, and there's LOTS I don't know. (see later re: class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." & vbcr
' used in inputbox dialogs


2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

Again,
Thanks to all. Your help is very much appreciated.
Neal Z.
--
Neal Z


"Jake Marx" wrote:

> Ni Neal,
>
> Neal Zimm wrote:
> > In an application that I'm developing I have dim'd quite a few
> > variables in Declarations. I'll admit some of it is not wanting to
> > take the time to put those vars that are used quite often in many
> > macros within the sub SubName(var list) parenthesis.
> >
> > 1) What advice can you offer on the pro's and cons of this technique?
> > All of the application's code is in ONE module.
>
> I don't like to declare variables at module level or globally (Public
> keyword in standard module) unless I have to. Some reasons are readability,
> ease of maintenance, and knowing your variables won't be "trounced upon" by
> various procedures. Module-level and global variables will also use more
> resources.
>
> The alternative is to pass variables via arguments to functions/subroutines.
> It is undoubtedly more work upfront, but IMO it pays off to do it this way.
>
> > 2) I got 'bitten' when testing a macro where a var called Draw was
> > dim'd as integer in Declarations, had a good value > 0 in prior
> > macros, but was 0 in the macro I was testing.
> >
> > Sure enough, I had dim'd it again, inadvertantly, also as Integer
> > in the macro being tested. Hence the 0 value, I guess. The QUESTION
> > is, why did I NOT get a duplicate Dim error?
>
> Well, since the variables had different scopes, it wasn't a duplicate
> declaration. You had one module-level variable named Draw, and you had a
> local variable named Draw with a completely different value.
>
> --
> Regards,
>
> Jake Marx
> MS MVP - Excel
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>
>

[Neal Zimm]

Thanks to all for the sound advice, I hope y'all don't mind a common response.
I'm relatively new to the VB game, self taught (with help from this bulletin
board)
, and there's LOTS I don't know. (see later re: class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." & vbcr
' used in inputbox dialogs


2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

Again,
Thanks to all. Your help is very much appreciated.
Neal Z.
--
Neal Z


"Bob Phillips" wrote:

> Use a class with properties, or maybe a collection class.
>
> --
>
> HTH
>
> RP
> (remove nothere from the email address if mailing direct)
>
>
> "Dave Peterson" <[email protected]> wrote in message
> news:[email protected]...
> > How about if you're picking up tons of values from a worksheet(s) that are
> used
> > in lots of different subroutines.
> >
> > I've used an initialization routine that returns all those values into
> global
> > variables.
> >
> > Jim Thomlinson wrote:
> > >
> > > Good coding practice is to use global or module level variable
> declarations
> > > as little as possible. The big reason is that it makes the code very
> > > difficult to debug. At any given time it can be difficult to know the
> value
> > > of a variable because all procedures can access it. One small change to
> one
> > > procedure can have side effects on all of the procedures that access
> that
> > > variable. The problem is that when you make the change it is not at all
> > > obvious what all of the consequences are. If you are passing the
> variable
> > > then it is reasonalby obvious. The only reasons that I ever use Globals
> are:
> > >
> > > 1. I need a value determined at run time to persist. An example might be
> a
> > > password to log into some subsystems. I get the user to enter it once
> and
> > > that value is stored for as long as the program runs. Any time I need to
> log
> > > into the subsystem I just call up the value. I don't have to worry about
> who
> > > changed the value last becuase it is only set once at the beginning of
> > > exectuion.
> > >
> > > 2. I have a function or sub procedure that is called repeatedly (great
> for
> > > recursion). In order to speed up the exectution I will have it use
> global
> > > variables so that the variables do not need to be created and destroyed
> each
> > > time the procedure is called.
> > > --
> > > HTH...
> > >
> > > Jim Thomlinson
> > >
> > > "Neal Zimm" wrote:
> > >
> > > > In an application that I'm developing I have dim'd quite a few
> variables in
> > > > Declarations. I'll admit some of it is not wanting to take the time to
> put
> > > > those vars that are used quite often in many macros within the sub
> > > > SubName(var list) parenthesis.
> > > >
> > > > 1) What advice can you offer on the pro's and cons of this technique?
> All of
> > > > the application's code is in ONE module.
> > > >
> > > > 2) I got 'bitten' when testing a macro where a var called Draw was
> dim'd as
> > > > integer in Declarations, had a good value > 0 in prior macros, but was
> 0 in
> > > > the macro I was testing.
> > > >
> > > > Sure enough, I had dim'd it again, inadvertantly, also as Integer
> in the
> > > > macro being tested. Hence the 0 value, I guess. The QUESTION is, why
> did I
> > > > NOT get a duplicate Dim error?
> > > >
> > > > Thanks.
> > > > --
> > > > Neal Z
> >
> > --
> >
> > Dave Peterson
>
>
>

[Neal Zimm]

Thanks to all for the sound advice, I hope y'all don't mind a common response.
I'm relatively new to the VB game, self taught (with help from this bulletin
board)
, and there's LOTS I don't know. (see later re: class variables.)

My uses of 'declared' vars in most cases, fall into all of the categories
mentioned.

1. vars where the values DON'T change, but are used by many subs. My
application is called "RM" and
I have a sub called zRM_Values which is called at the begining of larger
macros. (BTW, I have a bad
right pinky finger and typing quotes "" is a bother)

2 examples:

declared: dim Yes as string
in the zrm_values sub, Yes = "Y" , so in any other macro: if
other_var_name = yes then .....

declared: dim PressEnter as string
in zrm_values: PressEnter = "Press Enter or click OK after typing.." & vbcr
' used in inputbox dialogs


2. I have tried mightily to have the module declared vars fall into two
other categories:

a) they have the same meaning in any macro in the module so
if the value is changed, it's kinda a good thing for me that other macros
have access to the 'latest' value.

b) I don't care if the value changes.
example: dim x as integer

since I use option explicit, without dim'ing x in every procedure,
I can use: for x = 1 to whatever


3. I have not learned what a "class with properties" is yet, nor
what a collection class is. Is the Excel help adequate on this topic
or can you recommend other reading sources?

Again,
Thanks to all. Your help is very much appreciated.
Neal Z.
--
Neal Z


"Bob Phillips" wrote:

> "Neal Zimm" <[email protected]> wrote in message
> news:[email protected]...
> > In an application that I'm developing I have dim'd quite a few variables
> in
> > Declarations. I'll admit some of it is not wanting to take the time to put
> > those vars that are used quite often in many macros within the sub
> > SubName(var list) parenthesis.
> >
> > 1) What advice can you offer on the pro's and cons of this technique? All
> of
> > the application's code is in ONE module.
>
> Personally, I try and keep this to a minimum, as it is always possible that
> in a procedure the variable will have a residual value from a previous
> procedure, preferring to use arguments. Yes, I know we should always
> initialise, but it is too easy to be lazy and rely on the default initial
> value.
>
> The pros and the cons are the same things really, they keep the value across
> procedures, they have (at least) module scope, and so on, it would depend
> upon the application as to whether that is a pro or a con. What I am saying
> I guess is that each variablke should be carefully considerred before either
> placing in Declarations or a procedure.
>
> > 2) I got 'bitten' when testing a macro where a var called Draw was dim'd
> as
> > integer in Declarations, had a good value > 0 in prior macros, but was 0
> in
> > the macro I was testing.
> >
> > Sure enough, I had dim'd it again, inadvertantly, also as Integer in
> the
> > macro being tested. Hence the 0 value, I guess. The QUESTION is, why did
> I
> > NOT get a duplicate Dim error?
>
> Because it is not a duplicate. The first was a module scope variable, the
> second was a procedure scope variable, it is quite legitimate to have both.
> When you do, when in the procedure with the procedure scope variable will
> be the one used, as you experienced.
>
>
>

[Bob Phillips]

Neal,

"Neal Zimm" <[email protected]> wrote in message
news:[email protected]...
> Thanks to all for the sound advice, I hope y'all don't mind a common
response.
> I'm relatively new to the VB game, self taught (with help from this
bulletin
> board)
> , and there's LOTS I don't know. (see later re: class variables.)
>
> My uses of 'declared' vars in most cases, fall into all of the categories
> mentioned.
>
> 1. vars where the values DON'T change, but are used by many subs. My
> application is called "RM" and
> I have a sub called zRM_Values which is called at the begining of larger
> macros. (BTW, I have a bad
> right pinky finger and typing quotes "" is a bother)
>
> 2 examples:
>
> declared: dim Yes as string
> in the zrm_values sub, Yes = "Y" , so in any other macro: if
> other_var_name = yes then .....
>
> declared: dim PressEnter as string
> in zrm_values: PressEnter = "Press Enter or click OK after typing.." &
vbcr
> ' used in inputbox dialogs

This sound more like a constant than a variable

Const Yes As String = "Y"

declared and initialised in one statemenmt

> 2. I have tried mightily to have the module declared vars fall into two
> other categories:
>
> a) they have the same meaning in any macro in the module so
> if the value is changed, it's kinda a good thing for me that other macros
> have access to the 'latest' value.
>
> b) I don't care if the value changes.
> example: dim x as integer
>
> since I use option explicit, without dim'ing x in every procedure,
> I can use: for x = 1 to whatever
>
>
> 3. I have not learned what a "class with properties" is yet, nor
> what a collection class is. Is the Excel help adequate on this topic
> or can you recommend other reading sources?

I would suggest at this stage you don't bother with classes. Whilst they are
useful, they are rarely an absolute necessity. My point was really at Dave's
statement.

[Neal Zimm]

Absolutely the same as a constant. Many thanks. I'm changing the code now.
you have helped me knock out about 40% of the declared vars.
--
Neal Z


"Bob Phillips" wrote:

> Neal,
>
> "Neal Zimm" <[email protected]> wrote in message
> news:[email protected]...
> > Thanks to all for the sound advice, I hope y'all don't mind a common
> response.
> > I'm relatively new to the VB game, self taught (with help from this
> bulletin
> > board)
> > , and there's LOTS I don't know. (see later re: class variables.)
> >
> > My uses of 'declared' vars in most cases, fall into all of the categories
> > mentioned.
> >
> > 1. vars where the values DON'T change, but are used by many subs. My
> > application is called "RM" and
> > I have a sub called zRM_Values which is called at the begining of larger
> > macros. (BTW, I have a bad
> > right pinky finger and typing quotes "" is a bother)
> >
> > 2 examples:
> >
> > declared: dim Yes as string
> > in the zrm_values sub, Yes = "Y" , so in any other macro: if
> > other_var_name = yes then .....
> >
> > declared: dim PressEnter as string
> > in zrm_values: PressEnter = "Press Enter or click OK after typing.." &
> vbcr
> > ' used in inputbox dialogs
>
> This sound more like a constant than a variable
>
> Const Yes As String = "Y"
>
> declared and initialised in one statemenmt
>
> > 2. I have tried mightily to have the module declared vars fall into two
> > other categories:
> >
> > a) they have the same meaning in any macro in the module so
> > if the value is changed, it's kinda a good thing for me that other macros
> > have access to the 'latest' value.
> >
> > b) I don't care if the value changes.
> > example: dim x as integer
> >
> > since I use option explicit, without dim'ing x in every procedure,
> > I can use: for x = 1 to whatever
> >
> >
> > 3. I have not learned what a "class with properties" is yet, nor
> > what a collection class is. Is the Excel help adequate on this topic
> > or can you recommend other reading sources?
>
> I would suggest at this stage you don't bother with classes. Whilst they are
> useful, they are rarely an absolute necessity. My point was really at Dave's
> statement.
>
>
>
>