Intro to series on quality VB.Net

Recently, there was a discussion on twitter regarding the sophistication of VB.Net development.  It’s worth noting that there is a very firmly held belief among C# developers that VB developers care less about the quality of their own work and that they are not interested in good techniques or self-improvement.  Interestingly, there is a related belief that VB.Net as a language is so inadequate that it is literally impossible to code using what is generally understood to be good practices.  For those of you out there that may be primarily VB.Net developers, I am NOT attacking you, (continue reading to see that) but it’s worth knowing that in the greater .Net world, your reputation isn’t so good, and that may be affecting your job prospects-strategize accordingly.  Practices increasingly well accepted in Java and C# are barely making a dent in common VB.Net development at this point.  As it is, VB programmers trying these accepted ideas may feel like trailblazers… and frankly, that’s pretty tiring work that not everyone is up to.  Convenient that in the C# world, the path is getting fairly clear.

Personally, I have done a fair amount of both C# and VB.Net, and find that it’s definitely possible to write code that follows widely accepted principles in VB.Net.  There’s nothing in the language that actually prevents use of ORMs like NHibernate, IoCs like Windsor, or SOLID principles.  Admittedly, I feel VB.Net is wordy to the point of being more difficult to scan visually, has some silliness (see AndAlso vs And) is missing some nice featues (see auto properties and lambdas), and tool support is weaker than for C#(see Resharper, and even Visual Studio itself).  I find C# to be an overall lower-friction coding exerience.  However, there are many developers who still code in VB.Net, whether because of preference or because of the situation on a particular project. They’re doing the same job as the C# programmers, in a language that’s fundamentally pretty similar to C# and can even interact directly with C#.  I want to let developers of both stripes know that VB doesn’t mean having to give up good practices. 

In that spirit, I’ll be doing a series of as-yet indeterminate length on implementing these practices, focused primarily on VB.Net, with C# for clarification or contrast where helpful. 


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *