Consequences of not declaring variables

yhgtbfk

Registered User.
Local time
Today, 22:21
Joined
Aug 30, 2004
Messages
123
What are the consequences of not declaring variables.

ie: instead of doing

Dim a
Dim b
Dim c

a = ..........
b = ..........
c = ..........

I just jump straight into

a = ..........
b = ..........
c = ..........

Am I going to run into problems?
 
declaring variables

If your talking about programming in general, like in VB for instance, declaring variables is always recommended by using the Option Explicit statement in the general declarations of a form. This forces variables to be declared so if you mispell them later in your code you will get an error message of an undefined variable. It also conforms to easier debugging if you name your variables according to standard naming conventions. Look up "hungarian notation" for an example. Highly recommended and also allows other programmers to follow your source code when sharing or working in a group. Also, if you declare a variable without specifying a datatype, it gets declared as a variant type which uses more memory. For instance:
Dim strMyName As String
is the same as saying Dimension the variable strMyName as a String type variable.

Dim strMyName
without explicitly defining a datatype as String will actually define it as a Variant.

At least in VB
HTH,
sorebrain :D
 
Last edited:
Yes that does help, thank you
 
Failure to define variables ahead of time also defeats any third-party tools you might buy to help you analyze your code. The debugger is going to have a harder time reporting things to you 'cause it won't know ahead of time how they are defined. The object explorer will have fits with reporting what you have in your code. AND you can never declare anything global unless you declare it explicitly. Which means you can never build a "true" new object-type in you applications if that is what you need to do. I.e. one for which you can do property puts, property gets, and the like. You are stuck with the stuff VBA defines.

Another thing that Option Explicit does for you is increase the nuisance factor during debugging, but it's a temporary nuisance that also happens to help you debug a lot faster. You see, when you predeclare a variable's type, VBA is then allowed (and able) to give you the "Type Mismatch" error when you store something in that variable that doesn't match the original declaration. When things are not predefined, they are declared as variants. ANYTHING can go into a variant and it is NOT AN ERROR to change types within the variant. You'd say, so what, but the first time you store a double on top of a single and find that something else has been glitchified, you'll curse yourself for hours trying to find the bug.

Much as I hate to find a type mis-match, it is why I always program my VBA with Option Explicit turned on. Or when I do other languages, I prefer Ada to C++, 'cause Ada (strong typing language) catches your mental errors whereas C++ (weak/no typing language) rarely does. You have to use a separate analysis tool or by a non-ANSI C++ compiler to get strong typing.

I've been around a while. Counting my college career, I've been programming at some level for 35 years, roughly speaking. I've learned that strong typing is a TOOL to help you get the crud out of your code. When you treat strong typing as a true inconvenience that you turn off, - trust me on this - no one but you will EVER want to touch your code. Further, you wouldn't like the names those other potential maintainers would call you. And it is a good way to get your code tossed into the round file the first time someone has to fix it.

Finally, if you have to go back and fix your own code after a few years on some other project - ANY other project - you will find that your mind will not recall the details of why or how a particularly nasty sequence works with its untyped variables.

By the way, that wasn't meant to be a diatribe or an insult. I'm just listing the reasons you want to use strong typing.
 
The_Doc_Man said:
By the way, that wasn't meant to be a diatribe or an insult. I'm just listing the reasons you want to use strong typing.

Im one of the few people who take criticism as a positive thing. Thank you.

I am still trying to digest everything you have said, but it makes sense.

I do have two questions though:

1/ How do I declare Option Explicit variables? I know how to create them within the sub, but how do I create them as global?
2/ What is the correct way of reffering to a control. ie: If I have a control called "myTextbox", within the code, do I type:

myTextbox = ...........

OR is there a better way?

Again, thank you very much
 
This may help...

To do this is a little tricky at first as you need to be looking at a form with design view and then select:

Tools|Options and on the EDITOR tab, place a checkmark in:

Require Variable Declaration

If you try to do this from the other window, like the default view, you can still see the Tools|Options but it won't get you to the same options :eek:

I am still learning but it looks something like this on question #2:

Private Sub Operator_Exit(Cancel As Integer)
Forms![frmCustomer]![CustomerID].SetFocus

This example takes the CustomerID field from the frmCustomer form and using the SetFocus event, sets the focus to the CustomerID field after it exits the Operator field on the subform.

Maybe not the best example but it may give you an idea of whats involved when you are just learning like me :) HTH
 
Last edited:
If the control you are referencing is on the form you are coding you can use Me.MyTextbox.
 
1/ How do I declare Option Explicit variables? I know how to create them within the sub, but how do I create them as global?

This is an apples/oranges question.

Option Explicit goes in the declaration part of a module. For instance, let Access create a class module for you in a form. Use a wizard to build a command button on an otherwise "virgin" form. Then look at the form's class module. The wizard created the module for you so it could populate the class module with the button's event code. In so doing, it build a good if somewhat clunky template for you. The Option Explicit statement will be right near the top of the class module. Any lines immediately following this statement and before the first entry-point code declaration (sub/function) are in the declaration area.

Dim statements can go in the beginning of the module (in the declaration area after Option Explicit) or in a function or sub. Normally they must appear before the first executable line of code in the thing you are making. When they appear in the module's declaration area, they are shared among all subs/functions within that module regardless of what you do. If they are defined in the header for an individual sub or function, they are private to that particular routine unless you declare them PUBLIC.

You could also declare them PRIVATE as a matter of consistency, but in that context they already ARE private (VBA keyword for "local" in any other language). Look up the syntax of PUBLIC (which is VBA's name for "global" in any other language) while you are at it.

You can declare a variable as public anywhere, but it is only truly public when it appears in a general module. I.e. go ahead and declare a public variable in a class module. It is still only visible in that class module, though it can be shared among the subs & functions within that module. But then, if it were declared in the declaration area of the class module, that would have been true anyway.

2/ What is the correct way of reffering to a control. ie: If I have a control called "myTextbox", within the code, do I type:

Well,... the name "myTextbox" can be referenced by itself in the code if that name is unique. But as a general rule, use Me.text-box-name as the preferred way in forms and/or reports when it is an intra-form reference. In that context, Me.x is always valid if x exists.

If it is an INTER-form reference, the full syntax is form-name.text-box-name and the correct name for form-name depends on whether the form is opened once {form.textbox}; more than once {Forms(n).Controls("text-box-name")} - and you have some work to do to determine the correct number of "n"; or not at all (not available).
 

Users who are viewing this thread

Back
Top Bottom