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 | 9 comments

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 9 comments

Comment added on 01 November 2011 at 19:09 GMT
Comparing Apples and aPPlEs

If you use visual studio like a real programmer and use intellisense, you'll never have this problem. It's also silly to use names like aPplEs, normally you use camel/pascal casing for naming.

And it's handy when creating classes. You name the private field something like 'age' and the public property that exposed the field 'Age'. This way you don't have to name it differently or do something like '_age' or 'm_age'.

Also you can hold the shift key instead of using caps lock to type in uppercase.

Silly Brackets

Personally I find those braces look good, they put some space between the if's, while's, ...

Those Wretched Semi-Colons

you don't have to put round braces after Length, it's a property. And if you don't put them how does anyone know the difference between a method with no parameters and a property/field?

Curly Brackets Everywhere

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

The Horrible Switch Operator

If I'm not mistaken visual basic is the only language that allows things like 'between 5 and 10' so when you switch over to another language you got to adjust a lot more.

And after a while you get used to all of that.


Ok maybe it doesn't seem all that logic to use + for concatenation but is it really such a big deal?

Redimensioning arrays

So you would really use an array when you have to store a variable amount of objects? There are better ways to do that like Lists.

Redimming arrays seems silly to me.

Option Explicit

Yeah you had to use overloads if you wanted to implement optional arguments. But what if that optional parameter is a type like datetime? If I remember correctly it can't be done for some types...


To me it seems logic to go to the designer and do it 'the hard way'. I think there's be a reason why the creators of visual studio didn't do it like that in c#...
Reply from Andy Brown
Good point about the private/public properties in classes. I also agree that lists are probably a better way of storing information that arrays. Thanks for sensible points! I was being slightly tongue-in-cheek, but I still don't really "get" Visual C# ...
Comment added on 24 November 2011 at 04:42 GMT
I have to agree with this article.  I program in both but prefer VB.  Also, I like building WPF apps in VB.  You can auto include namespaces and even classes.  I find it also simple more readable.
Comment added on 19 December 2011 at 12:08 GMT
Another reason: I've just tried to use the PMT function in C#, to calculate mortgage payments.  It turns out this is a VB function, and I have to reference the VisualBasic namespace to get at it!
Comment added on 23 January 2012 at 13:44 GMT
I graduated from University last year, I was taught VB.NET and C# but I was very inexperienced with it.

I found the VB.NET was easier to learn, I became a little confused when I began learning C# because I would mix up VB.NET and C# syntax together.

So I recommend to anyone learning a programming language pick one you like, become good at it, and then consider learning additional languages.

There were things I like in C# more than VB. But my preference is VB.NET.
Comment added on 16 February 2012 at 05:39 GMT

I totally disagree with every point made in this article. Many of the 'reasons' are related to not being bothered to observe strict ruling and formatting that exists in C#. These rules and formatting exist for a reason and learning to work with them is valuable for any programmer.

Visual Basic is a great learning tool, which is why it is taught in many universities. Unfortunately, as a programmer you cannot simply survive on one language, and you'll need to always be learning new languages and technologies. C# is closer to Java, C, C++ and other languages, therefore minimising the learning curve.

I began learning both VB and Java at the same time. Once I graduated I needed to learn C# and I now code in both VB and C# everyday (as well as a bunch of other languages, albeit less frequently). I personally find C# code nicer to read, better structured and faster to develop.

I would encourage anyone starting out to not make their decision based on direct comparisons such as this, but more so on their preference after trying both. Also consider what skills are in greater demand. I believe that in terms of .NET development, C# at the moment is is greater demand.

Reply from Andy Brown
I agree that C# is in greater demand (we teach more C# courses than VB), and also agree that if you know Java or C++ you're a lot closer to learning C# than you are to learning VB. However, neither of these are comments on which language is easier to learn from scratch!
Comment added on 13 March 2012 at 12:40 GMT
I normally try to be neutral on the merits of the two different languages. My preference is for c#, so I am a little biased.

For the most part the two languages are functionally equivalent. However, I have found and frequently run into one glaring problem. C# will allow code to implement interfaces when VB.Net will not recognize this implementation. This often has implications to my software designs.

If I have an interface that requires a getter on a property, c# will not complain if the implementation also has a setter. VB.net on the other hand will not consider the interface implemented. 

I have also found in clunky and cumbersome that you had to explicitly state what each method or property was implementing. C# will automatically match the method signatures and property names to determine what is matching what. With VB.Net you have to explicitly state what is what and this is the only work around to the limitation mentioned earlier.

If you have one interface requiring a getter and a separate interface requiring a setter, the one property can implement both interfaces in C#. With VB.Net, two separate properties will be required.

Before I understood this limitation, I had 3 interfaces that my UI needed to implement. One required a get for a dozen or so properties. One required a set for the same properties. The final one specified a a get and set for each of these properties. Everything worked well in csharp code, but when another developer insisted on doing the UI in VB, we were both shocked to discover that we needed three times as many properties as anticipated.

Granted, this turned out to be a bad design for our application, but this is a limitation that few people acknowledge.

What are your thoughts on this?    Have I missed something in VB?
Reply from Andy Brown
A good point, although not quite in the same category as case-sensitivity, I feel! I don't know how to do this in VB, and a quick ask-round at the owlery reveals nobody else does either.
Comment added on 03 April 2012 at 00:44 GMT
Well my first programming language was C, and I learned programming the hard way, not because of the language, but because of I graduated electrotechnical high school, and everybody at college was expected to know programming in Pascal or C. After that I learned C++, Java and finally C#, my true love.

I really like your examples of why you don't like C#, it makes me remember my first days of C.

1. Case sensitiveness makes variable names more readable. 

2. Those curly brackets, makes code more readable and defines the scope for variables, very useful if you want to hide stuff, but you don't need them if you have short logic. Use them in pair so you don't forget to put one, It takes time to get used to it, but in time it will repay you the pain to search for these type of errors.
// here c = 0 only if a > b, c = a + b all the time
if(a > b)
   c = 0;
c = a + b;

// this code block executes only if a > b
if(a > b)
   c = 0;
   c = a + b;

3. Semi-colons ends a statement. Useful for writing less code, but it can be misused.
// is shorter than to put every statement on a new line
a = b = c = d = 0;

// the evil way
a = 0; b = 0; c = 0; d = 0;

4. The switch statement is the good old one from C. The breaks control the flow of the logic, why complicate things with composed cases when you can skip ahead ? Relational operators in a case clauses ? Now way, let the flow take you, and leave the more complex logic in a function or in a if statement.

5. It's called operator overloading, when you give a different meaning for an operator in a different context. Concatenation in C# is done by the + operator, or with the StringBuilder's, Append method. It is very useful when it makes sense in the context.

6. Redimensioning arrays, makes you feel more alive, literally. Visual Basic does the same thing in the background, but you don't notice this, I like to know if a particular array is new or old.

You don't have to bee a nerd to use C#, you just need a different mindset.
Reply from Andy Brown
Thanks for the comments (and apologies for the late moderation of your comment). My defence of VB is slightly tongue-in-cheek, but there are some angry C# trolls out there who take it WAY too seriously!
Comment added on 11 February 2013 at 09:49 GMT
I have always been using VB.net, so I am indeed biased ...
In the future, apparently, I will have to use C#.
So, C# fans, please prove your point (that C# is as good as, or even better than VB.net) :

I am used to this :
... Handles btn1.Click, btn2.Click, btn2.Click
which means : the method code also shows what its purpose is (WhereUsed of the method, so to speak).
So my question is :
for a given method in a class in C#, how can I retrieve a similar WhereUsed ?
(to check if I can safely alter the method, or even, if it is still needed)
Comment added on 01 September 2013 at 18:35 GMT
Its just may be because some are "born" in programming C/C++ to C#, and some in VB6 to VB.Net. And if you are born a C programmer its tedious and awkward to end an "for" or an "if" statement with and "end for" or "end if." respectively. And also to us there is no art in naming variables, just plain logic. We hate wasting our time thinking of other suitable word for a variable just because the variable is already used but in different letter case. If "&" is more logical for string concatenation than "&" why other programming languages like ruby and python prefer to use use "+" for string concatenation and not other symbol?

A full-blown discussion forum is being built for this site, which will allow you once more to add comments and discussion threads.