A customer recently requested that I provide them with Microsoft's VB.NET coding standard for their developers to use on our project. To prepare my document I referenced the Visual Basic Coding Conventions located on MSDN. While reading this article I found some surprising recommendations that I very much disagree with.
Naming Conventions
“Use namespace qualifications rather than adding Imports statements. If a namespace is imported by default in a project, you do not have to fully qualify the code because it will run unqualified with Intellisense when copied and pasted.”
My comments: Qualifications cause maintainence nightmares when the location of classes or namespace structures change. I recommend using import statements.
New Keyword
”Use short instantiation” i.e. “Dim employees As New Collection()” instead of “Dim employees As Collection = New Collection()”
My comments: The long instantiation is not much longer and is consistent with other CLR languages.
MsgBox Function
”Use MsgBox instead of MessageBox.Show or Console.WriteLine.“
My comments: MsgBox is old VB6 style. MessageBox.Show is consistent with other CLR languages.
Use My Namespace
“Use My features in preference to the .NET Framework class library or the Visual Basic run-time library.”
My comments: More VBisms... Other CLR lanuages use the .NET Framework class libraries.
Use the Visual Basic Run-Time Library Members
“Use the Visual Basic run-time library in preference to the .NET Framework class library.”
My comments: Come on... The VisualBasic32 libary should not be used.
All of these recommendations encourage developers to write VB.NET code in the old VB6 style. This goes against the common sytax that .NET brought to the table. They also contribute to making VB seem like a higher level lanuage than other CLR languages, which encourages the VB is for less technical developers argument. The fact that VB.NET is full of VBisms and we encourage their use is very disheartining...