How to develop a standard (C# vs. VB.NET)

Question

So, I don't want this to get into a flame war between C# and VB.NET developers. This is purely from a standpoint of a development department going forward. We've been a VB.NET company for years, but that was mainly due to who we've hired. That requirement has fallen off the wayside as of late, as we've pulled in 2 guys who specialize in C#. I used to be a C++/C# guy before converting to VB.NET for this company.

So, to everyone who has to deal with this whether on a hiring basis or a maintainability basis: how do you handle standardizing languages of choice going forward? I'm inclined to make a push for C#, as that'll make 3 solid C# developers here. But just curious what everyone's thoughts on this are.

Answer 1

As someone who works in a mixed shop, it's not that hard to get by using both. But it helps to have a standard that makes it easier to move code back and forth. Here are few ideas for your standard:

For the VB Developers:

• Disallow old vb6-style functions in new code. I'm talking about string and other functions (Len, InStr, Replace, UBound, etc). The convert operators (CInt, Cstr, etc) are still okay because they are language operators, but prefer a Convert.To___() function where possible for easy conversion to and from C#.
• Require Option Strict and Option Explicit. You'll give up some dynamic typing coolness by making it a requirement vs a strong suggestion, but it's worth it to keep the code parity with C#.
• Standardize on '+' vs '&' for string concatenation (if you're not already using a StringBuilder)
• Prefer AndAlso and OrElse over And and Or

For the C# Developers:

• Disallow names that differ only by case. This especially includes names that are basically the same as the type name (SomeType sometype = ...). Tell them to use an _ prefix instead (and not "m_"). You should do that anyway but it's especially important in a mixed shop because that code will be harder to work with in VB.

For both:

• Disallow ArrayLists and other non-generic collections (because not only are they evil anyway, but VB and C# handle the all required casting very differently, even with option strict thanks to CType)

If you do this, there will be few real differences between the code for the two groups, and you've taken the first step toward teaching the VB developers to think like C# developers.

Answer 2

If you have a lot of code that is already written in a particular language, prefer that language.

Otherwise, if you have more developers well-versed in one language over the other, prefer that language.

Otherwise, prefer C# (it is generally more popular, and feature-wise they aren't different enough to make a meaningful choice over features alone).