The top 10 reasons for me why C# is better than VB.NET.
1. In C# the line ends when I type the semicolon. The practical offshoot of this is that I write code like this:
string sql = @"SELECT *
FROM SomeSuchTable
WHERE ID='WhatHaveYou'
ORDER BY ThisAndThatField ASC ";
So when someone hands you a SQL statement you can just paste it into your code and the output (i.e. carriage returns) will still keep the format. In VB.NET, you would have to write the following to keep the formatting.
dim sql as string = "SELECT *" & vbCrLf
sql += "FROM SomeSuchTable" & vbCrLf
sql += "WHERE ID='WhatHaveYou'" & vbCrLf
sql += "ORDER BY ThisAndThatField ASC "
And that's annoying.
2. Increments/Decrements. a++;a--; 'Nuff said
3. Money. No, not the data type. The green. C# developers make more money. Don't believe me? Here is the proof. Like Orwell said, War Is Peace, Freedom Is Slavery, Ignorance Is Strength and yeah, it's the same .NET framework, but Perception is Reality. Get over it. Learn it. Put it on the resume.
4. I am not sure whether this is a valid reason, but with C# I can use Borland C# Builder which sports my beloved SDI interface, a la VB3, so that you can code full screen. This interface was also available (though not by default), in VB4,5,6 and VS.NET 2002 beta 1. The SDI interface disappeared from the VS.NET product before it shipped though. Anyway, if you miss that kind of interface, you can use it in Borland C# Builder.
5. Error Catching. C# catches a lot more errors than VB.NET, such as uninitialized variables, dead code, etc...
6. You get to act really snotty to VB.NET developers, yeah! That's priceless.
7. The source code to the C# compiler is available from Microsoft and Novell. This means that you can theoretically develop apps for OSes other than Windows, such as Linux and MacOS. Thanks to Jai Lue for this tidbit.
8. C# has Operator Overloading (my favorite feature from C++). Though, via the grapevine, VB.NET will have this feature in VS 2005. Thanks to Aditya Vaze for this language delicacy.
9. Comments in C# are just better. You can do multiline comments, XML comments, single line comments, etc... Thanks to German Voronin for this.
10. Regions in C# are far better. The key here is that you can place a region inside a function, thus breaking up the implementation into logical pieces. I simply love this ability.
Here are the top 10 reasons why VB.NET is better than C#
1. # 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"))
2. # The Intellisense in VB.NET is smarter than the one in C#. The most maddening example involves enums. Consider these screenshots:
C#
VB.NET
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.
3. # Optional Parameters. Even though it is syntactical sugar, it helps you code faster. 'Nuff said.
4. # With..End With construct. Does anything else need to be said? Really?
5. # 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.
6. # 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:
VB.NET
'instantiate a textbox
Dim a As New TextBox()
'Update some class
With MyClassName
.ThisProperty = "sss"
.ThatProperty = "sss"
.ID = 4
.Name = "Frank"
End With
C#
//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"
7. # Events. Extremely easy to both declare and raise in VB.NET. In C# you have to be a delegate expert. Consider the following code:
Class Example
Public Event SomethingOccured()
Public Sub Method1()
RaiseEvent SomethingOccured
End Sub
End Sub
End Class
Class Papa
Private WithEvents oExample as new Example()
Private Sub SomethingChanged() Handles oExample.SomethingOccured
...
End Sub
'or use AddHandler function
AddHandler oExample.SomethingOccured, AddressOf x
Private Sub SomethingChanged()
...
End Sub
End Class
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.
8. # More refined Error Handling using the Catch ... When block. See below
Do
Dim attempt As Integer
Try
' something that might cause an error.
Catch ex As IO.FileLoadException When attempt < 3
If MsgBox("do again?", MsgBoxStyle.YesNo) = MsgBoxResult.No Then
Exit Do
End If
Catch ex As Exception
' if any other error type occurs or the attempts are too many, do the following.
MsgBox(ex.Message)
Exit Do
End Try
' increment the attempt counter.
attempt += 1
Loop
Thanks to German Voronin for this.
9. # 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.
c#
case 1
case 2
case 3
(...) // Do Action
break;
case 4
break;
vb.net
case 1,2,3
(...) ' Do Action
case 4
10. # Ah, I am still working on this...
