After having converted a whole lot of training materials based on VB.NET into C#, Andy 'Wise Owl' Brown decided to write a tongue-in-cheek rant whilst he could still remember the pain-points. 'Convert to VB.NET! You have nothing to lose but your semi-colons! '
Visual Basic is a better programming language than Visual C#. Who says so? This article! Here are 10 reasons why you should always choose VB over C#.
1 – "Rose is a rose is a rose is a rose"
This is a quotation from Gertrude Stein's 1922 play Geography and Plays. However, the poetry wouldn't work in C#, because – unforgivably – it's a cASe-SeNSitIvE language. This is madness!
Before I start ranting, let me just acknowledge that case-sensitivity confers one (and only one) advantage – it makes it easier to name private and public properties:
Writing properties like this means that you can refer to the public Name property, and it's obvious what the private equivalent will be called (name). | // private version of variable
private string name = null;
public string Name
{
get
{
return txtName.Text;
}
set
{
name = txtName.Text;
}
} |
So now we've got that out of the way: case-sensitive programming languages make everything else harder. Why, you ask?
- You keep having to switch between upper and lower case when typing, causing RSI in your poor little fingers as you reach for the inconsiderately located Shift key.
- You are much more likely to make mistakes - are you sure you meant to type DateOfBirth, or should it have been dateofbirth?
- When you accidentally leave Caps lock on, it really matters.
The only possible benefit is that you can use more combinations of variable names, that is, you can use more of one of the few infinite resources in this universe…
It doesn't matter if you disagree with everything else in this article: case-sensitivity alone is sufficient reason to ditch C#!
2 – The Switch clause
Both VB and C# contain a way of testing mutually exclusive possibilities, the Select Case and Switch clauses respectively. Only one of them works properly.
A Visual Basic Select Case clause, returning a description of how old someone is. The age range for a young person is a tad generous, reflecting the age of the author of this article.
A Visual Basic Select Case clause, returning a description of how old someone is. The age range for a young person is a tad generous, reflecting the age of the author of this article. | Select Case AgeEntered
Case Is < 18
txtVerdict.Text = "child"
Case Is < 50
txtVerdict.Text = "young person"
Case Is < 65
txtVerdict.Text = "middle-aged"
Case Else
txtVerdict.Text = "elderly"
End Select
|
You can't do this using Switch in C#, as - astonishingly - it can't handle relational operators. You have to use an If/ Else If clause instead. But even if you could, you'd still have to type in lots of unnecessary Break statements:
switch (AgeThreshold) {
case 18 :
txtVerdict.Text = "child";
break;
case 50 :
txtVerdict.Text = "young person";
break;
case 65 :
txtVerdict.Text = "middle-aged";
break;
default:
txtVerdict.Text = "elderly";
break;
} | It's easy to forget to type in each of these Break statements! |
3 – Event-Handling code
This is specific to Visual Studio (I'm using 2010, the latest version). Suppose I want to attach code to anything but the default Click event of a typical button:
 | Let's suppose that I want to attach code to the MouseHover event of this button. |
I can do this in Visual Basic without leaving the code window:
a) First choose the object from the drop list. |  |
 |
b)Then choose the event you want to code. |
In C# you can't do this – you have to return to the button's properties window and choose to show its events:
 | You can double-click to attach code to this event for the selected button – but that's the only simple way to create it for C#. |
But it's even worse than that. If you then rename a control (in this case btnApply) you have to re-associate the event-handler with the renamed control in the properties window (or in the initialisation code, if you can find it). In Visual Basic, of course, you can do all of this in code:
Private Sub btnApply_Click(ByVal sender AsSystem.Object, ByVal e As System.EventArgs) Handles btnApply.Click MessageBox.Show("Hello") End Sub | Globally change btnApply to the new button's name in code, and everything will work as before. |
4 –Stupid symbols
C# was written by academics. It shows. Consider this table of C# symbols and their VB equivalents:
| What you're trying to do | C# Symbol | VB Equivalent |
| Test if two conditions are both true | && | and |
| Test if one or other condition is true | || | or |
| Test if a condition is not true | ! | not |
| Concatenate two strings of text | + | & |
| Test if a condition is true within an if statement | == | = |
Which column looks like it was designed by a real person?
5 – Autocorrection in Visual Basic actually works
IntelliSense works much better for Visual Basic than for Visual C#. Take just one example – creating a write-only property. Let's start with Visual Basic:
 | When you press return at the line end… |
WriteOnly Property PersonName As String Set(value As String) End Set End Property | … You get this fully-completed clause. |
For C#, the same thing doesn't happen:
 | When you press return here, nothing happens (other than a blank line appearing). |
This is just one example. I've just spent ages transcribing our VB courses into C#, and believe me, there are many, many more!
6 – Lack of supported functions
Here are a couple of functions I use from time to time in VB:
| Function | What it does |
| IsNumeric | Tests if a value can be converted to a number |
| PMT | Calculates the annual mortgage payment for a loan |
Great functions, but they don't exist in C#.
7 – That wretched semi-colon
Why do I have to end every line in C# with a semi-colon? The argument used to be that it avoided the need to use continuation characters in Visual Basic:
MessageBox.Show( _
text:="This article is a bit opinionated", _
caption:="Message") | You used to have to use an underscore as a continuation character to show incomplete lines of code in VB. |
However, as of Visual Basic 2010 you rarely need to do this anymore. Come on, C#: Visual Basic has ditched its line-ending character; why can't you?(;)
Someone commented on my original (much shorter) blog about this:
"In a short amount of time you'll type those semi-colons without thinking about it (I even type them when programming in visual basic)."
That's like saying that you'll soon get used to not having any matches to light your fire, and you'll even start rubbing sticks together to start a fire when you finally manage to buy a box!
8 – Arguments and variables
The order of words in a C# variable declaration is wrong. When you introduce someone, you wouldn't say, "This is my friend who's a solicitor; he's called Bob". So why do you say:
string PersonName = "Bob";
To me:
Dim PersonName As String = "Bob"
…is much more logical. I also find the C# method of having to prefix arguments with the word out confusing, particularly as you have to do it both in the called and calling routine.
9 – Strictness
C# is a much fussier language than Visual Basic (even if you turn Option Strict on in Visual Basic, this is still true). "And a good thing, too!", I hear you cry. Well, maybe. Consider this Visual Basic code:
Enum AgeBand
Child = 18
Young = 30
MiddleAged = 60
SeniorCitizen = 90
End Enum
Select Case Age
Case Is < AgeBand.Child
MessageBox.Show("Child")
Case Else
MessageBox.Show("Adult")
End Select | With Option Strict turned on this shouldn't really work, as it's comparing an integer with an enumeration – but VB has the common sense to realise what you want to do. |
The equivalent in Visual C# doesn't work:
A less forgiving language…
What this means is that you end up having to fill your code with messy type conversions:
The simplest way of converting an enumeration to an integer; but why should you have to? | // find out the age entered
int Age = Convert.ToInt32(txtAge.Text);
if (Age < (int) AgeBand.Child) {
MessageBox.Show("Child");
} else {
MessageBox.Show("Adult");
} |
10 – Redimensioning arrays
If you want to dynamically change the length of an array in Visual Basic, you can use Redim Preserve. To do the same thing in Visual C#, you have to copy the array, add a value and then copy it back:
The vile, clunky C# method of extending an array. | string[] PartyGuests = new string[2];
PartyGuests[0] = "Sarah Palin";
PartyGuests[1] = "Richard Dawkins";
// whoops! forgot to invite Mitt
// create a new extended array
string[] tempGuests = new string[PartyGuests.Length + 1];
// copy all of the elements from the old array into new one
Array.Copy(PartyGuests,tempGuests,PartyGuests.Length);
// add Mitt as last element
tempGuests[PartyGuests.Length] = "Mitt Romney";
// restore full list into original array
PartyGuests = tempGuests;
// check works
foreach (string Guest in PartyGuests) {
System.Diagnostics.Debug.Write(Guest);
} |
This epitomises Visual C# for me. Critics will tell me that:
- Behind the scenes, the Redim Preserve command does exactly the same thing as the C# code above; and
- I should be using lists and not arrays anyway.
That's hardly the point! The point is that - as so often - Visual Basic makes something easier to code than C# does.
Conclusion
So those are my 10 reasons to code in Visual Basic. What are you waiting for, all you C# code-monkeys? Convert all of your code to VB – you have nothing to lose but your semi-colons!
use of 3rd party add-ins like SQL Prompt ($195). But these tools are a horrible hack at best (e.g. they hook into the editor window and try to interpret what the application is doing). 
Posts
