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.

 

[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.

 

[Jake Marx]

Ni Neal,

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]

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?

 

[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.

 

[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)

 

[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.

 

[Bob Phillips]

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

--

HTH

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

 

[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".

 

[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 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 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

Ni Neal,

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

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

--

HTH

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

 

[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.

 

[Bob Phillips]

Neal,

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.