Very few programmers have the luxury of toiling on their code for a really long time - we are expected to
churn apps out in a quick manner. Which means that to be productive, we must use tools that enable us to be that.
So let's get practical, religion aside, with an eye on programmer productivity, here are the top 10
reasons why VB.NET is better than C#, in no particular order
The amount of data casts and conversions in C# is gigantic. There are probably 10 casts per
50 lines of code. Most of the time these casts are totally unnecessary, like in this common example.
I normally save the state of the form either to Ini file, Registry or XML file. So on application
startup, I restore Form's state:
//get the form state from Ini File
//following line fails
FormWindowState eState = oIni.GetValue("FormState");
//must use cast (FormWindowState)
FormWindowState eState = (FormWindowState) oIni.GetValue("FormState");
//even this does not work
FormWindowState eState = 1;
//you have to use a cast even on simple numbers
FormWindowState eState = (FormWindowState) 1;
//finally set the value
this.WindowState = eState;
So here we have a case where Form.WindowState should accept value such as 1, but refuses to. IMO,
the compiler should be able to convert on the fly. I don't mind strong typing. I do mind stupid
typing. In VB.NET all the lines below work.
me.WindowState = 1
me.WindowState = val(oIni.GetValue("FormState"))
The Intellisense in VB.NET is smarter than the one in C#. The most maddening example involves enums.
Consider these screenshots:
Note that in C#, you had to type out the enum type (FormWindowState), before Intellisense appeared.
Which means you had to remember what it was. While in VB, the intellisense appeared right after the
= sign, sparing you the having to remember the enum type belonging to the WindowState property.
Intellisense in vb.net goes beyond this. Let's say you declare your variables in mixed/Hungarian
notation, and then type my code later all in lower case. VB.NET autocorrects the case.
It is a quick visual confirmation that your syntax and variable names so far are correct.
Thanks to Jai Lue for this insight.
- Optional Parameters. Even though it is syntactical sugar, it helps you code faster. 'Nuff said.
- With..End With construct. Does anything else need to be said? Really?
- Handles keyword. Currently in C# you have to setup the signature for the event handler and
and then provide the function elsewhere. This is like C for god's sake. Where as in VB, you provide the
description of what the function handles right in the function via the Handles keyword.
The word is that C# will eventually provide anonymous methods (i.e. providing event code at signature).
Will reevaluate this when we get there.
- In C#, you do a LOT more typing. The common consensus is that C# is much less verbose than VB.NET,
That's a total misconception. Consider the following pieces of code and then count the bytes:
'instantiate a textbox
Dim a As New TextBox()
'Update some class
.ThisProperty = "sss"
.ThatProperty = "sss"
.ID = 4
.Name = "Frank"
//instantiate a textbox - Word 'TextBox' had to be written twice
TextBox a = new TextBox();
//Update some class - count how many times MyClassName had to be typed???
MyClassName.ThisProperty = "sss"
MyClassName.ThatProperty = "sss"
MyClassName.ID = 4
MyClassName.Name = "Frank"
- Events. Extremely easy to both declare and raise in VB.NET. In C# you have to be a delegate expert.
Consider the following code:
Public Event SomethingOccured()
Public Sub Method1()
Private WithEvents oExample as new Example()
Private Sub SomethingChanged() Handles oExample.SomethingOccured
'or use AddHandler function
AddHandler oExample.SomethingOccured, AddressOf x
Private Sub SomethingChanged()
As you can see extremely easy and no need to much with delegates which are a lot more code-intensive.
Now, mind you, VB.NET still fully supports the delegates, but for 99% of the time standard events do the trick.
- More refined Error Handling using the Catch ... When block. See below
Dim attempt As Integer
' something that might cause an error.
Catch ex As IO.FileLoadException When attempt < 3
If MsgBox("do again?", MsgBoxStyle.YesNo) = MsgBoxResult.No Then
Catch ex As Exception
' if any other error type occurs or the attempts are too many, do the following.
' increment the attempt counter.
attempt += 1
Thanks to German Voronin for this.
Another reason is the Switch Block(Select case) syntax. For very large state machines this comes in very handy.
Reuse of a single case statement for multiple items and no break statement required.
(...) // Do Action
(...) ' Do Action
Thanks to Brian Yule and Vashon Kirkman for this piece.
- Ah, I am still working on this...