WiseOwl Training - Established 1992 Wise Owl Training

Established May 1992
30 years in business
Wise Owl Training
30 years in business
See 479 reviews for our classroom and online training
Why you should program in Visual Basic, not Visual C#
If you're beginning .NET application development with a clean slate, you'll need to choose a programming language. VB or C#? This opinionated blog gives you some guidance!

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. 

Stop press: I've put a 10th reason in a separate blog - the nightmare of raising events from user controls in C#.

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:

  1. It makes it much more likely you'll make mistakes when coding; and
  2. 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




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;




// 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


Dim qty As Integer = 0


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;


case "subtract":

i -= 1;


case "multiply":

case "divide":

ErrorText = "Not covered";



ErrorText = "No other possible words allowed";


This is worse than the VB construct in two ways:

  1. 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.
  2. 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!


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!


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:

Choosing an object in VB 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:

Choosing an event

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:

Event properties for a button

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 ... !

This blog has 0 threads Add post