The Conservative Nature of VB (Part 4) – Use Before Assignment
Number 4, in my series regarding the Visual Basic warning settings. This one is an interesting one but comes from a long held problem from the days of old in Visual Basic. Using a variable before anything has been assigned to it. In languages like C# and C++ variables need to be assigned before they can be used, in C# if you have some simple code;
int myNumber; if (myNumber == null) Console.WriteLine("My number is null.");
There will be an error reporting the use of an unassigned variable. Why? Often it is the way the items are created in memory. The application will request an address for the Integer (4 bytes) to store the value that will be aliased by myNumber. You get the address space and it contains what WAS at that address, it could be nothing it might not be.
I am aware that int types are not nullable. But it is an example only.
But in VB, this is a different kettle of fish. All intrincic types are assigned a value when it is created. Take the following code;
Dim myNumber As Integer If myNumber = 0 Then Console.WriteLine("My number is 0") Else Console.WriteLine("My number is " & myNumber.ToString()) End If
Fairly simple as far as a VB application is concerned. But if you open the the assembly of the application, you will notice;
mov dword ptr [ebp-40h],0
This says, move the value 0 into a double word (32bits) pointing to the ebp (display the registers to see the value of this)minus 40H. So, without performing any initialisation at all, I was able to declare the value and the compiler was able to pre-initialise it for me.
So a note, if you were to enter the above VB code into your VB application, set the value of the warning to match this;
But you might noticed no warning comes about regarding numeric types these include integral and floating point numbers. In VB it seems that the gods have decreed
In Visual Basic whence a number variable has been declared, thus forth it shall be initialised with 0, and it is good.
So understanding this means that you don’t need to initialise these numeric data types. But SHOULD you? It is good programming practice to intiialise all variables before use because you can come unstuck quickly when using types that aren’t initialised.
Dim myList As List(Of Integer) If myList.Count > 0 Then Console.WriteLine("There are items") End If
So the above code, looks OK, but I am getting a warning telling me the use of an uninitialised variable could result in an error. And in this instance, it will.
Well one might say that is poor coding since I didn’t catch the exception, but this is another conundrum of development should I make sure I catch all errors, or prevent errors from happening, which will be the subject of my next post.
Errors happen, but this error could have been prevented with one simple keyword.
Dim myList As New List(Of Integer)() If myList.Count = 0 Then Console.WriteLine("There are NO items") End If
New. The code executes as intended and the warning goes away. This is a handy item to have turned on, simply because it will allow you to know where there is the possibility of errors creeping into your code if the initialisation of this is dependant on the user.
NOTE Just a quick note this will also look at variables that are passed by reference that has not been assigned. These variables might be used as return values from calling procedures due to the reference being passed, but it still might be used before that, and the reference is unknown at compile time and therefore checks like that can’t be done until run time.
Another note, yeah I know. This is one that I might recommend as an Error setting. The other languages, like C# and C++ will not compile if there are uninitialised variables, therefore it might be good to have VB not compile if it finds these errors too. Though the main difference is the numeric types in VB are initialised, C# and C++ they are not.