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

We've recently had the same issue. We actually just code in both, depending on what the original project was started in. It's surprisingly easy to switch back and forth, especially with Visual Studio (it always "reminds" me when I start typing "bool myvar..." that I'm doing something wrong if I'm in a .vb file).

Our priority goes like this:

• Use an existing language if we already have code for this project/customer
• Use the language that the customer prefers, if they care
• Use C# otherwise (this is only because there are way more examples out there in C# when you're trying to find a code snippet to get you through some problem quickly)

Answer 3

Having good reasons to go with one standard over another should be the guiding factor. Use these:

1. VB.NET seems much more verbose than C#. (ex: "Dim var as MyClass" vs "MyClass var")
2. C# is similar to C++ and Java. VB.NET is similar to... well, nothing. (unless you count VB6...)
3. Try making a ragged array in VB.NET. I dare you.

Answer 4

1. Talk to some local recruiters, find out what the available skillsets are in your area, if you were to hire more developers. What is available should affect your choice.
2. Make sure your developers can work with your current codebase, no matter what the language
3. Ask your developers for their preference, since they may base their decision to stay with the company down the road on the technology.
4. Have a look at support for those languages in your specific industry. For example, a law firm might need a lot of MS Office and VBA integration. Using VB.NET might have cross-training benefits. Or you might be in an industry that uses a lot of C++, C, or Java based tools. Using C# might be more natural to those programmers.
5. Look into what sort of training resources you have available in those languages. If you can get more or cheaper training for one specific language, you might want to favor it.
6. Start thinking about your plan to transition to another language down the road. Even if you standardize today, what about 5 years from now? Or 10? Languages change, needs change.

Answer 5

If there is a single reason to adopt C# for your company it is the lambda operator. Without the full support of the lambda operator in VB.NET some of the best tools become either crippled or DOA. For example: Fluent NHibernate, StructureMap etc.

Answer 6

It sounds like you already have a standard - VB.NET. And maybe you are tempted or interested in getting into C# instead.

It makes very little sense to have half your systems written in VB and half written in C# - although depending on the nature of your organisation this may not apply. But generally, the organisation shouldn't take these changes lightly.

If I was you (and you are interested moving to C# for yourself) then I'd push for C#, but if I was the business then I would need a very good reason to introduce this new complexity, cost & management issue.

Answer 7

The question you are asking is actually very important, and too many people will tell you that language choice is just personal preference. But you already know that, from the standpoint of an organization, this is not true. Choosing a standard set of frameworks, languages, tools, etc. is an important business decision.

Your programmers should be able to use either language with a little time, encouragement and maybe a little training. C# and VB are close, and there are no significant technical reasons to choose one over the other...

So my advise is to pick your organization's language based on businesses reasons. If hiring C# guys is easier, or if you find they tend to have better skillsets for the kind of work you do then score one for C#. If you write code for customers, and those customers prefer C# deliverables then score another for C#. If you have existing code in VB, score one for VB.

It should be a pretty simple breakdown... just ignore technical reasons and concentrate on how the choice of language will affect your business in terms of hiring, training, ability to deliver to the customer, etc.

Answer 8

That is entirely dependent on the developer pool you have.

Answer 9

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).

Answer 10

At a previous client, who had written their mission critical apps in VB, they started to find it more difficult to find VB programmers as opposed to C#.

So they decided to start switching their apps to C#.

As with most IT/Dev questions, the answer is it depends. If you have more people in your department who are great with VB, then go with VB. I don't think one of is that much better than the other.

Answer 11

Some years ago we standardized on c# because c# seems to have more of a following among serious developers.

Let me be clear I am not saying anything bad about VB.NET or those who use it.

Answer 12

On a purely capabilities basis, they are about as close as two languages can get. VB.NET tends to get more COM interactivity and has literal XML -- but C# is getting some of that soon.

It's really just personal preference and what language you think the team can be most productive in.