The Moth

Although everybody concedes that language choice is a matter of taste on the .NET platform, we still encounter phrases such as "VB encourages bad programming style" or "VB is not clean" or "VB performs worst" and other similar comments on the same theme, which derive from VB.NET carrying baggage from the VB6 days.

There is bad .NET code running around, but it boils down to who writes the code and not what language it is written in. The truth is that it is easier to write smelly code in VB.NET than in C#. To that extent I have a set of rules that I follow when coding in VB and, rather than trying to pull them out of my head every time I get asked, I thought I'd post this so I have something to point to from now on.

So, in no particular order, this is how I do VB in .NET style:

1. Always turn on Option Strict, Option Explicit

2. Use Try..Catch instead of On Error Goto/Resume Next/Err.Xxxx

3. Use AndAlso, OrElse instead of And, Or. Write your conditions so they do not need to use And, Or for logical comparisons.

4. Use shifting (<< >>) instead of multiplying/dividing when appropriate

5. Declare namespaces in code. So, delete the "root namespace" from Project->Properties->General

6. Use Return X instead of FunctionName = X, PropertyGetname = X, Exit Sub/Function/Property

7. Use overloading instead of optionals.

8. In conditions, instead of stringA = stringB, use String.Equals(stringA, stringB).

9. Don't use modules. If you need the functionality they offer, just use Static (Shared)Classes.

10. Use DllImport, not Declare

11. Understand WithEvents and Handles and what they generate for you in IL. Use the alternative AddHandler/RemoveHandler where appropriate.

12. Understand CType, DirectCast and Convert.ToXxx methods and use them instead of CInt/CXxx, unless you really need the extra functionality the latter provide.

13. When exposing .NET classes to COM, don't use the ComClassAttribute

14. Don't use Microsoft.VisualBasic.Compatibility (this is different to the Microsoft.VisualBasic.dll)

15. Consider very carefully which namespaces you need imported globally (Project->Properties->Imports).

16. Remove the Microsoft.VisualBasic import from Project->Properties->Imports. This will force you to specifically add it when you need it in each file. At that point consider using the framework's functionality instead (or at least find out what the equivalent is)

17. In the MS.VB namespace, do not use the Strings, DateAndTime, FileSystem, VBMath, Collection [browse the library in Object Browser to see what's in them, find the framework's equivalent].

18. When doing release builds, check the "Remove Integer Overflow Checks" (and the other one)

Of course, some times your project is small or you just need to get the job done as fast as possible. Smelly vs Clean code is not in the picture, performance is irrelevant or dominated by other factors such as network roundtrips and, in any case, the app's life-expectancy is very short. In those cases, you may find VB's flexibility helping you get results faster. I've never had a project like that, but thought I'd mention it.

As always, rules are there for the breaking :-)