Variable Declaration - Does Location Matter?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Is there any difference between declaring a variable at the top of a method
versus in the code of the method? Is there a performance impact for either
choice? What about if the method will return before the variable is used?
I'm trying to get an idea of whether the .NET compilers for VB.NET and C#
will move all variable declaration to the beginning of a method or whether
they will allocate the memory as it is needed by the method to conserve
memory.

Example (VB.NET):
' Declaration at the top of a method.
Public Sub SampleSub()
Dim sMessage As String
' ... Other code that might exit the method early ...
sMessage = "Hello!"
End Sub

' Declaration in a method.
Public Sub SampleSub()
' ... Code that might exit the method early ...
Dim sMessage As String = "Hello!"
End Sub
 
In your case, they are syntactically identical. However, in the following
code, they aren't:

Public Sub SampleSub()
dim sMessage as String ' sMessage is available throughout SampleSub

for i as integer = 1 to 10
sMessage = i.tostring ' This works because i is local to the for
loop
next i

sMessage = "Final 'i' is " & i.toString ' This will fail because
i isn't available outside the for loop
End Sub

Mike Ober.
 
I respectfully disagree with your assessment of where to put a Dim.

It is my opinion that you should put all your declarations at the top of a
sub in alphabetical order. I think it's just tidy programming. In general,
sub/functs shouldn't have very many variables anyway. If you find yourself
creating a huge list of variables, then you are not breaking your code down
into appropriate routines in my opinion.

Just a thought.
 
Shawn Brock said:
I respectfully disagree with your assessment of where to put a Dim.

It is my opinion that you should put all your declarations at the top of a
sub in alphabetical order. I think it's just tidy programming. In general,
sub/functs shouldn't have very many variables anyway. If you find yourself
creating a huge list of variables, then you are not breaking your code down
into appropriate routines in my opinion.
Click to expand...

No, it's not tidy programming IMO. It's bunching unrelated stuff
together. Keeping it as close to the first usage, within the tightest
scope possible keeps it tidier. It also helps you to make sure you
don't accidentally use an "old" value later on in the method where you
*really* wanted a new variable.

Also, putting them in alphabetical order removes the information about
which variables are related.
 
1. In VB, I believe that Dim is an executable statement, whereas with C,
declarations have to be at the top of a block of code (ie at the top of a
{..} sequence). A modest performance improvement should exist for a VB
return preceding a dim. It could be significant if there are a lot of dim's
and/or big and complex initializers.

2. I think it is a good idea to locate a dim statement in conjunction with
its usage/scope with a sub. If a variable is used throughout a sub, then dim
it at the top of the sub. If it is used in a small area of a relatively
large sub, then dim it near where it is used. If you dim within an if-then
block (for example), you do limit the scope of the variable. The following
sub will compile ok:
Private Sub x()
Dim Something as boolean
If Something Then
Dim b As integer
End If
' b=0 ' under option strict, this will not compile because b is not
declared
End Sub
Above, the scope of 'b' is the 'then' block.

3. Continuing the above example (both Basic and C), if boolean SomeThing is
false, the 'then' block will not execute, and that includes dim'ing 'b'. If
there are many dim statements with initializers, the performance change may
be significant.
 
Alphabetical doesn't make much sense to me. With i and j for for-loops and
interval for something else, there is no good reason to replace 'dim i, j as
integer' with dim i, then dim interval, and then dim j. Also, if you use
initializers with your dim statements, then sometimes you have to order your
dim's so the initializers are well defined, eg
Dim sra As Reflection.Assembly = Reflection.Assembly.GetExecutingAssembly
Dim MyStream As IO.Stream = sra.GetManifestResourceStream("somename")
Dim Buffer(CInt(MyStream.Length)) As Byte
Here, MyStream depends on sra, Buffer depends on MyStream, Buffer is as big
as it needs to be, and the code is economical and understandable.
 
I took a different understanding of the question. It's not the declaration
location that is changing in the example, but where it is assigned the value
"Hello!"

Does this make any difference?
 
It's all about where the variable is declared, not where it is assigned.
The location that a variable is declared determines its "scope" or lifetime
or accesibility.

Here are ALL the VB.NET levels of scope:

The smallest scope there is in VB.NET is "Block Level Scope". A "block" of
code is anything that can be written in a procedure that has a beginning and
an end. For example, For...Next, If...End If, Try...End Try, Select...End
Select are all examples of blocks of code. Be careful though because a
block may contain smaller blocks inside of it:

If foo then
'this is a block
elseif foo then
'this is a different block
else
'this is a different block
end if

So, anything declared in a block is only accessible from within that block.
The variable pointer itself will stay in memory until the procedure ends.

Anything declared within a procedure, but not in a block with the word Dim
has "Procedure Level Scope" and is accessible from anywhere in the procedure
(including inside of blocks). The variable pointer itself will stay in
memory until the procedure ends.

Anything declared within a procedure with the keyword Static will is
accessible as if it was declared with Dim (in or out of a block) but with
the difference that the variable's value will not be lost when the variable
falls out of scope. If the program should re-enter the procedure, the
variable's last value will still be accesible.

Anything declared at the module level (not inside a procedure) with the
keyword Dim or Private is accessible from any procedure within the module.
The variable pointer itself will stay in memory until the module is removed
from memory.

Anything declared with the keyword Protected is accessible as if it was
declared Private at the module level with the exception that it is also
accessible from classes that derive from the class the the keyword was used
in.

Anything declared with Freind is accessible anywhere in the assembly that
the declaration appears in.

Anything declared with Public is accessible anywhere in the assembly as well
as outside the assembly.

Anything delcared as a Web Service is available from other machines via a
web reference.

Anything in a Web Service that is declared as a Web Method is available to
be called by the remote machine that has made an instance of the web service
class.
 
Back
Top