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.