My Beef With Visual Basic .NET
9/27/2006 1:26:19 PM
I`m not a C# elitist or Visual Basic .NET hater but there are some piss-off points when I end up working on or supporting a VB.NET application. When I first started learning .NET I was writing code in Visual Basic .NET because I came from a Visual Basic background. Over time (especially if I have the choice) I have switched to writing everything in C#. I have even gone so far as to rewrite entire Visual Basic .NET applications or functionality in C#. There are many VB v/s C# debates out there and this isn`t one of them. I`m simply sharing my top 2 beefs (at least with the IDE).
My list of beefs (not all-inclusive) with Visual Basic .NET
- No multi-line commenting in Visual Studio: This is small and nit-picky but to me it`s important.
- No regions within methods: Again, nit-picky but very important to me. I like to think of my screen as real estate, especially when debugging large, complex projects. Adding stored procedure parameters, logging events, error-handling, etc.. can all be "regioned" out. This leaves more important code visible on the screen. I am also a big fan of regioning out sections of the program that have been tested and are in working order. Maybe it`s just a personal thing, but it`s not fun stepping through a routine that is 500 lines* long (that should have been modularized in the first place!) without regioning huge chunks of it.
Of course I consider myself deft when it comes to VB / C#. It`s good to know both (especially for troubleshooting purposes and supporting apps from years back), but if I had to choose one it would definitely be C#.
* I don`t think I have ever had a routine anywhere near 500 lines. If I can`t explain in a sentence what it does then it gets granularized.
.NET,
C#,
Programming,
VB.NET
