BLOGS BY TOPIC▼
BLOGS BY AUTHOR▼
BLOGS BY YEAR▼
Posted by Andy Brown on 10 October 2011
You need a minimum screen resolution of about 700 pixels width to see our blogs. This is because they contain diagrams and tables which would not be viewable easily on a mobile phone or small laptop. Please use a larger tablet, notebook or desktop computer, or change your screen resolution settings.
Why you should Program in Visual Basic, not Visual C#
If you're starting to develop an application, the chances are high that you'll need to choose between Visual Basic (or VB) and Visual C# (or C Sharp). Which is better?
The title of this blog shows it gives a firm recommendation, but this doesn't mean it's biased. Wise Owl run lots of courses in Visual Basic and Visual C#, so we have no axe to grind (or "ax", for those reading this in the US).
I haven't numbered the reasons below, but I think I got to about 9.
Comparing Apples and aPPlEs
If you call a spade a SpAdE, are you giving it a new name? You are in Visual C#. So in the example code below, we've created two different variables:
// two different variables
int AnyNumber = 1;
int anyNumber = 2;
This has two main effects:
- It makes it much more likely you'll make mistakes when coding; and
- It makes typing code much slower, since you will continually have to keep switching CAPS LOCK on and off.
And what do you get in return? The ability to create more variable names. But letter combinations are one of the few things in the world in infinite supply ...
Silly Brackets
Consider the following sample of code (it's not important what it does):
Protected Sub btnShow_Click(ByVal sender As Object,
ByVal e As System.EventArgs) Handles btnShow.Click
'the word entered
Dim WordText As String= ""
'the length of the word
Dim TextLength As Integer = 0
'find out word user typed in
WordText = Me.txtWord.Text
'work out its length
TextLength = WordText.Length
'show length of input word
Me.lblResults.Text = WordText & " has " &
TextLength.ToString & " letters"
End Sub
If this were written in C#, you'd have to put round brackets after Length and ToString. I'm sure there's a good reason for this - it's just that I don't care what it is!
Those Wretched Semi-Colons
In C# you have to end every statement with a semi-colon, which is irritatingly unnecessary. The C# code below contains two mistakes:
// everything OK - display answer
lblProductOrdered.Text = ProductName
lblQuantityOrdered.Text = Quantity.ToString()
The obvious retort to this is that in Visual Basic you have to use an underscore to split lines, because there's no line ending character. Which would be fair comment, except that from Visual Studio 2010 you no longer need to do this:
'show length of input word
Me.lblResults.Text = WordText & " has " &
TextLength.ToString & " letters"
The VB code above would still compile, even though it's a split line.
Curly Brackets Everywhere
C# uses {} brackets everywhere. One disadvantage of this is that it makes it much harder to see where blocks of code begin and end, and where you've either missed out a } or over-indulged. Compare this property in C#:
// property to read and write quantity
integer Quantity
{
get
{
integer qty = 0;
try {
qty = Convert.ToInt16(txtQty.Text);
}
catch {
qty = 0;
}
// return value typed into text box, or 0 if couldn't validate it
return qty;
}
set
{
// change text box value
txtQty.Text = value.ToString();
}
}
with the equivalent property in Visual Basic:
' property to read and write the quantity
Property Quantity As Integer
Get
Dim qty As Integer = 0
Try
qty = Convert.ToInt16(txtQty.Text)
Catch ex As Exception
qty = 0
End Try
Return qty
End Get
Set(ByVal value As Integer)
txtQty.Text = value.ToString
End Set
End Property
Yes, the VB equivalent involves more typing (although autocompletion means this actually isn't true), but it's so much easier to find mistakes.
Microsoft seem to agree. Visual Studio will only set the indentation of a block of code in C# once you've typed in every single } bracket - for Visual Basic it is much more forgiving.
The Horrible Switch Operator
Visual Basic allows you to use an alternative to the IF statement, which is SELECT CASE. For example:
'first find out what trying to do
Dim TextOperatorPassedInSomehow As String
Dim i As Integer = 42
Dim ErrorText As String = ""
Select Case TextOperatorPassedInSomehow
Case "add"
i += 1
Case "subtract"
i -= 1
Case "multiply", "divide"
ErrorText = "Not covered"
Case Else
ErrorText = "No other possible words allowed"
End Select
Nice and clear? The equivalent statement in C# is switch:
// first find out what trying to do
string TextOperatorPassedInSomehow;
int i = 42;
string ErrorText = "";
switch (TextOperatorPassedInSomehow) {
case "add":
i += 1;
break;
case "subtract":
i -= 1;
break;
case "multiply":
case "divide":
ErrorText = "Not covered";
break;
default:
ErrorText = "No other possible words allowed";
}
This is worse than the VB construct in two ways:
- There is - unbelievably - no way to use relational operators in case clauses. So if you want to test if a variable is between 5 and 10, say, you're going to have to use an IF statement in C#. Likewise, we have to include two separate lines for multiply and divide above.
- For every case clause in a switch statement, you need to break at the end. How annoying and unnecessary is that?
Yes, I know, you can always use if and else instead in C# - but you shouldn't have to!
Concatenation
It is just plain illogical to use the same character - + - to add and concatenate:
Dim i As Integer = 1
Dim s As String = "Wise "
i = i + 1
s = s & "Owl"
Some VB code is shown above - in C# you'd have to use + for both of the last two lines.
Redimensioning arrays
In Visual Basic, you can change the size of an array that you've created easily:
'create an array to hold 3 Beatles
Dim Beatles(2) As String
'set them into array
Beatles(0) = "John"
Beatles(1) = "Paul"
Beatles(2) = "George"
'Ringo joins
ReDim Preserve Beatles(3)
Beatles(3) = "George"
In C# you just can't do this: instead, you have to create a new array with a different size and copy all of the elements from the old on into the new one.
The annoying thing is that behind the scenes all that the REDIM PRESERVE statement does is create a new, larger array and copy all of the elements from the old one to the new one. So why can't C# have an equivalent statement?
For more on the various structures available to you in Visual Basic and C#, see our benchmark speed comparison blog.
Option Explicit
You can now declare optional arguments in C# - but it's only been introduced in Visual C# 2010. Not a valid niggle any more, I suppose, but I still thought I'd bring it up!
Event-Handlers
Although I've listed this as the last reason to program in VB and not C#, in many ways it's one of the most important. C# just makes everything to do with events more complicated. Compare how you attach code to web page's button in the two languages.
For the example shown, you could just double-click on the button in design view for both languages, but that doesn't work for most events.
In Visual Basic, you can choose an object in code view:
Click on the arrow shown, and choose the thing to which you want to attach event code.
You can then choose the event you want to handle:
You can then choose to which event you want to attach code (probably the Click event in this case).
In C# none of this is possible. Instead, you have to create an event in the button's properties window:
You can double-click on the event to create it - but to do this you've had to leave the code window.
There is much more on why events are so much harder work in C# - for example, raising events from user controls - but I think I'll leave it there.
Finally - the Other View
In the interests of balance, I ought to conclude with why you should program in C#, not Visual Basic. I can think of 3 reasons:
- You already know Java, JavaScript, C or C++.
- Your company uses C# as a standard.
- You're a programming nerd.
Perhaps the last point is a bit unfair ... !