The Conservative Nature of VB (Part 3) – Implicit Type
Number 3 in my series of posts about VB having these options that enable certain warnings from telling the programming something isn’t quite right with the code, or supress them. These aren’t errors in preventing the application from working, but errors might happen depending on the state of variables or, it is just a hangover from the origins of Visual Basic.
I am looking into the Implicit Type warning. This is really a hangover from the days of VB yore. Previously VB, including ASP would not be as strongly typed as the languages of today, evening Visual Basic 6 you could still declare variables without providing a data type
Yes, just like that. It would be created as a Variant which has a massive overhead in comparisons to other data types. So, why can I still do this in VB now. Well, the reason is unknown, possibly because of the conversion process. Applications converted from VB 6 or before to the new .NET version of VB, they might have thousands even more variables that have been declared that way. These no way to determine the physical data type so they were just created as Objects, which were the base class type for all data types in .NET
Are their issues with using Objects over the others, yes. The main issue is an Object in Visual Basic version 7 or greater are not compatible with Objects from Version 6 or less. So, accessing interop COM objects you can’t pass object variables.
A performance hit as you incur a penalty for late binding. Since if any method calls occur a look up to the object needs to be done to verify validity.
Widening is done to aide in the prevention of Overflow Exceptions, but there is an additional performance hit to box and unbox values types to the inherent reference Object type.
So, having this warning come up and say we have found variables you haven’t explicitly given a type we will make them all Objects, well you should go and fix them. It isn’t always clear what it might be, but sometimes providing and incorrect variable will cause an error in telling you that it can’t convert from this type into the type you provided.
Dim ReasonId = CInt(dlMain.SelectedValue)
This is a crude example but it is there for me to show how you can determine the data type needed if it isn’t straight forward, which I know the above example is.
I have updated with an unlikely data type;
Dim ReasonId As DataView = CInt(dlMain.SelectedValue)
Doing this has now caused an error in the code telling me it can’t convert one type to another.
So, this tells me that it can’t be converted to this and it tells you the type it needs to be. Update the code and everything will be OK.
Dim ReasonId As Integer = CInt(dlMain.SelectedValue)
Most of the time it is easy to tell but if using LINQ and other more complex types or collections (including the generics collection) then it isn’t as cut and dry.
Should you turn this option on to show a Warning or an Error. Well this depends on the project and also the programmer. Me, I am one who wants to fix this, and I am currently working on a project that has a LOT of these in it. Even for data types where they immediately initialise the variable.
Dim myVariable = True
This in my understanding is silly. Does it take that much effort to include As Boolean into the code. So, in my learned opinion all variables should be declared with a data types and should be turned on as an Error and converting older applications, turn it on as a Warning, as you can slowly go through and fix all the issues.