Aaargh! I thought to myself for the umpteenth time as I looked through my inherited VB.NET web site (it’s bad enough that it was a web ‘site’ with dodgy auto-generated (i.e. NO) namespaces), but the following things are now officially going on my list of reasons I choose C# over VB.NET. I know I shouldn’t care as it all compiles to the same thing, but (just from this project) –
- VB.NET still allows you to dodge the Option Strict and Option Explicit (definitely a ‘Web Site’, as there’s no option in the property pages like for any other standard .NET project). This means that you happily declare untyped variables, and do all sorts of dodgy late binding. Some people obviously like this facility, but it’s one of the things that holds VB programmers back in the world of object-oriented design.
- Modules still exist! OK you could argue this is just a public class with everything marked as static, but it’s still ‘global’, and you don’t need to reference the module name when you access a method or variable. This often leads to the ‘where the hell is that defined?’ question
- Variants still exist. This is obviously an extension of the first one, but it’s a big enough annoyance that people use to get themselves out of a (I don’t know how to implement this properly using object-oriented techniques) hole
- Syntax ‘feel’ – e.g. Me vs this, and MyBase vs base – it feels a bit ‘Mickey Mouse’.
- Verbose syntax causing RSI:
- #Region “String Constant” vs #region whatever you like without having to put quotes around (C# regions can also be indented with the code unlike VB)
- Global functions instead of operators like TryCast instead of ‘as’, CType instead of (Mytype)variable. CStr, Cint etc still exist. Not only is this more typing in many cases as you need to enter two or more parameters, it also feels like yet more ‘baggage’ from the bad old days, as you can still pass in your objects to generic ‘library’ functions rather than use methods on the object themselves (like ToString()). Many VB programmers will lap this up because the language still allows them and they don’t have to learn something new.
- #Region “String Constant” vs #region whatever you like without having to put quotes around (C# regions can also be indented with the code unlike VB)
- Case insensitivity. OK I’ll give you this one as it was one of the ‘speed’ things in VB6. It does lead you back to the horrible pseudo-hungarian thing (for some people) though as you get naming conflicts with properties and variables if you follow the general pascal/camel C# standard (can’t remember whether there’s an option to switch that off though). The alternative to the pseudo-hungarian notation is the _ prefix for class variables, but even that seems like too much of a concession.
- Methods can still look like properties. Call a method in VB without parameters and it will happily let you write MyMethod. This just feels like inconsistency.
- Tool support and productivity.
- VB.NET simply doesn’t have the same support in Visual Studio or refactoring addins (ReSharper’s only catching on to VB.NET now) This isn’t the language’s fault, but it’s easier to be more productive through tools with C#. (I know this is improved with every release of VS).
- The default VS 2005 refactoring capability (limited but present in some form) for C# is basically non-existent for VB.NET. Maybe Microsoft think VB programmers don’t need refactoring support?
- Intellisense is also generally rather lacking for VB.NET
- XML Documentation comments (just now catching up, but was really lacking)
- VB.NET simply doesn’t have the same support in Visual Studio or refactoring addins (ReSharper’s only catching on to VB.NET now) This isn’t the language’s fault, but it’s easier to be more productive through tools with C#. (I know this is improved with every release of VS).
- Angle brackets <> look uglier than square brackets [] for attributes (OK that’s a bit picky!)
The bottom line is that VB.NET lets you be sloppy, like VB always did. The problem is that a fair percentage of those who migrate from VB to VB.NET (not all I agree – don’t shoot me!) take the same shortcuts that they always did – because they still can.
My opinion is that on average you’ll find more elegant design, better formatted and more object-oriented code from C# programmers as they’re more likely to have come from a C++ or Java background.
Did I mention that I was a VB programmer for years, and have only dabbled a bit in Java and not really ever C++. I loved VB6 (at the time) as I could get systems written quickly and well. What I didn’t love was how much backwards-compatible support it kept leaving in with each new version, just so people could upgrade their crap legacy code. I’ve seen some very clear, consistent, well formatted and commented VB.NET code, but I’ve seen an awful lot more that’s not. The flip side is that C# coders often think they’re great just because they’re writing in C#. I’ve seen plenty of horror stories there too, but the ‘bad’ percentage is much lower (sorry – it just is).
VB unfortunately doesn’t encourage discipline in programmers, whereas C# benefits from a clean slate without the historical baggage. I believe the slightly more formal language specification of C#, and the fact it attracts more ‘OO’ coders, tends to lead people to think a little more about design rather than just skipping straight to implementation (which is where the ‘real’ problem is 🙂 ). You can write the same crap code in any language you like. VB unfortunately just makes it easier.