Tuesday, September 28, 2004
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
2. Use
3. Use
4. Use shifting (
5. Declare namespaces in code. So, delete the "root namespace" from
6. Use
7. Use overloading instead of optionals.
8. In conditions, instead of
9. Don't use modules. If you need the functionality they offer, just use Static (
10. Use
11. Understand
12. Understand
13. When exposing .NET classes to COM, don't use the
14. Don't use
15. Consider very carefully which namespaces you need imported globally (
16. Remove the
17. In the MS.VB namespace, do not use the
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 :-)
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 Explicit2. Use
Try..Catch instead of On Error Goto/Resume Next/Err.Xxxx3. 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 appropriate5. Declare namespaces in code. So, delete the "root namespace" from
Project->Properties->General6. Use
Return X instead of FunctionName = X, PropertyGetname = X, Exit Sub/Function/Property7. 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 Declare11. 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
ComClassAttribute14. 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 :-)
Labels: dot NET general
Copyright © Daniel Moth
