VB 2005 variable declaration syntax

  • Thread starter Thread starter Mark Berry
  • Start date Start date
M

Mark Berry

Hi,

I'm moving from VB6 to VB 2005. Two questions:

1. One book I'm using has syntax like

Dim testConnection as SqlConnection = New
SqlConnection(connectionString)

However, the Help for the Dim statement says, "If you use New, you do not
use an initializer expression. Instead, you supply arguments, if required,
to the constructor of the class from which you are creating the variable."
And in fact, it seems that the following code is also allowed:

Dim testConnection as New SqlConnection(connectionString)

Are these actually identical? Is the latter example the preferred approach?

2. If the constructor has no arguments, I generally see code like this:

Dim testCommand As SqlCommand = testConnection.CreateCommand()

However when I type this into the IDE up to the "CreateCommand" and press
Enter, the IDE leaves off the parentheses:

Dim testCommand As SqlCommand = testConnection.CreateCommand

This seems very strange, since when I call a method without assigning its
result, the IDE adds the parentheses, e.g. I can type up to Open and press
Enter, and the IDE will add the parentheses:

testConnection.Open()

So again I am wondering if the Dim statements with and without the
parentheses is the same and whether one is preferred over the other.

Thanks for any clarifications.

Mark
 
It's really a matter of personal choice.

1.

If you have a look at the generated IL you will find whether or not the
compiler produces the same IL for the 2 (slighty) different statements.

As far as I am concerned, the difference between the 2 statements - Dim X As
Y = New Y(<args>) and Dim X As New Y(<args>) is that the 2nd example
requires less typing. The compiler is 'brainy' enough to infer that the type
of X will be Y without it having to be explicitly specified.

There are situations where this approach does not work, e.g. Dim b As New
Byte(255) does not work and you must write it in full as Dim b as Byte() =
New Byte(255) {}. You could, of could also write it as Dim b(255) As Byte.

If the constructor of a type takes no arguments the you can safely leave the
parenthesis off, e.g., Dim X As New Y() and Dim X As New Y are both valid.

2.

CreateCommand is a method, not a constructor. In general, if a method takes
no arguments then you can safely omit the parenthesis. E.g., X =
Y.ToString() and X = Y.ToString are both valid. Again you may come accross
exceptions to this.


In my experience, code that is 'written' by an auto-generator (including
auto-completion via intellisense) will generally be 'written' in full, but
what is actually 'written' is determined by whomever programmed the
aparticualr auto-generator.

As you progress, you will also come across other anomilies in
auto-gernerated code. E.g., the form generator will write an Imports
System.Windows.Forms statement into the file but will also write fully
qualified statements withint the class such as Dim TextBox1 As
System.Windows.Forms.TextBox. At face value this might seem pointless but
it does serve a puupose in avoiding ambiguity if you happened to add add
your own class called TextBox to the project.

In conclusion, I reiterate that is not a matter of which one is more correct
but rather a matter of which style you prefer.
 
Dim testConnection As SqlConnection _
= New SqlConnection(connectionString)
Dim testConnection as New SqlConnection(connectionString)

Functionally identical and which you use is largely personal perference.

However ... things get a little /less/ flexible when you start playing
with Polymorphism, for example :

Dim oCtl As Control = Me.txtBox1

The actual control is a TextBox, but I want to manipulate it as a Control
(or some other Type that TextBox can be cast to).
2. However when I type this into the IDE up to the "CreateCommand" and
press Enter, the IDE leaves off the parentheses:

AFAIK, this is just another foible of the Visual Studio IDE, which will
probably break code in a later version which /insists/ on having the
braces ... ;-)

HTH,
Phill W.
 
Back
Top