VB.Net from a C# Perspective

Earlier in the week, in my post about the new job I mentioned that I was doing some VB.Net development.

The generally accepted belief is that since VB.Net and C# both compile down into the same thing, the languages are much the same, certainly that it’s not too much of a problem to cross-train.

I have to say that my experiences this week have no reason to disagree with that assessment. Given a good reference, an experienced programmer in one language shouldn’t have too much difficulty picking up and working with code written in the other. Having said that, there are some differences, some pretty subtle, that could either trip up, or just annoy someone making the crossover.

Perhaps the biggest annoyance from my point of view is how verbose everything ends up being when coding in VB.Net. Although Visual Studio will fill in quite a bit if you skip over it, there is still a lot more typing to accomplish the same thing. What is a bit frustrating (and I know this is an old VBism) is the way VB.Net uses two different constructs where C# uses one. Take functions and sub-routines. In VB.Net a function returns a result, and a sub(-routine) doesn’t. In C#, everything is a function, the equivalent of a sub(-routine) is a function that returns nothing, by using the void keyword. Looking at class definitions, in C# you can inherit from classes, and implement interfaces by just listing them in the definition following a colon (‘:’). VB.Net have the two words, ‘Inherits’ and ‘Implements’ followed by the relevant class and interface names.

So far I have only come across one issue that I regard as a major problem, and it is worth saying that this has been addressed in the 2005 release of VB.Net. Quite often when trying to write generic functions you want to check whether an object is a particular type, or implements a particular interface, and then cast the variable to that type to perform some actions on the object. When you run code through FXCop, it will always throw up an objection if you check the type, and then cast it as two separate calls, as this will unnecessarily cast the type twice, impacting performance. What it suggests is using the C# ‘as’ operator instead, as this will return ‘null’ if the object is not of the right type, rather than the other options which will throw an exception. In this way you make the conversion straight off into a local variable, and just have to check for null, knowing that if the variable isn’t null, then it is already the right type. To be blunt, you can’t do this in VB.Net prior to the 2005 release. However you try to convert the type, it will always throw an exception. You’re either faced with doubling conversions, or having your application generate and catch the exception, something that is even slower.

Having said that, there are some nice constructs. One that has made the transition from VB6 which aids readability – and in VB6 helped performance too, is the ‘with’ statement. Certainly for blocks of code where you are setting a whole series of properties and methods from the same object, it makes for more readable code.

I’ve only given a quick overview of some of the differences. Certainly if you’re a C# programmer handed some VB.Net or a VB.Net programmer handed some C# there is not too much to worry about. If you’re a non-technical manager who is in a situation such as the one I heard about recently where a C# team (many of whom had done VB6 before) refused to take over a project written in VB.Net until it had been entirely re-written for them in C#, I certainly think that it is financial lunacy to waste the resources doing the re-write, especially as the assemblies produced in each language interoperate directly. A good reference to each language, or a good conversion guide such as the excellent “C# & VB.NET Conversion Pocket Reference” by Jose Mojica, a bargain at only £6.95 are enough that any competent programmer in one language, should be able to work in the other.

If you’re starting a new project, the choice really comes down to other things, and to be honest I’d recommend people go with C# every time. Whilst there is an argument that VB6 programmers may find VB.Net easier, there are again some subtle problems to catch you out, and in some ways the whole way of thinking about an application is different. The new syntax in the C# might be easier to handle than the more subtle spot-the-difference that swapping between VB.Net and VB6 may produce. Quite apart from that there are more reference books, and more examples around written in C# – indeed out of all the .Net training and presentations I have seen, only a single, hour long session has been in VB.Net rather than C#


Also published on Medium.

3 thoughts on “VB.Net from a C# Perspective”

  1. I also have experience of all three languages (VB6, VB.NET and C#). Of the three, I most prefer C#. That’s probably because I learned, and was mostly happy with, C++ long before learning the others. I have to concede that you can be far more productive in any of the newer languages than in C++.

    I prefer the terseness of C# over the verbosity of VB. VB is superficially easier to read, but I find that I can actually read C# faster, since there’s less _to_ read. It certainly doesn’t hurt that C# is also faster to write – fewer, shorter keywords and symbols to type. OK, with VB you know which is the base class and which are interfaces (use of Inherits vs Implements), but since the convention is to name interfaces with a prefixed I, you already know that. All right, you can break the convention, while you can’t break the syntax (since the code won’t compile), but any reviewer will be very hard on breaking the convention.

    Again, from my C++ background and going back to my University days with Ada (another extremely verbose language), I like strongly-typed languages. VB doesn’t qualify unless (in VB.NET) you turn on Option Strict. Indeed the automatic conversions are downright dangerous. With Option Strict On, it becomes even more verbose, since you must now explicitly cast.

  2. Richard I think you have missed the point.

    VB.Net and C# are obviously going to be compared, but the point is that as it boils doen to the same thing, so there isn’t much point in doing a comparison. as the choice between the two is just personal preference.

    There is pains and pitfull is both languages IMHO and it is always handy to get to know them before you start coding anything in anger.

    So don’t be such a developer snob! 🙂

  3. That is the point that I was trying to make – since there are relatively small differences, attitudes such as the “we’re not supporting this because it is in VB.Net” don’t cut it, and as you say, starting a new project is entirely personal preference. However, it is important to remember that there are one or two gotcha’s between the two languages of which it is important to be aware.

    In terms of my preference, although I’m quite happily working away in VB.Net at the moment, I prefer C#, because of the many more examples and books that are circulating around, and because, like Mike, I prefer the more terse syntax that you get with C#. But as I said, I’m pretty easy about whether it is VB.Net or C#. Now if I were being a snob, I would have thrown all my toys out the pram at the mere prospect of having to do anything at all in VB.Net…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.