Choosing between Visual Basic .NET and C#

By Ted Pattison

For two years now I have been working with the .NET Framework. In this time, I learned to read and write code using both Visual Basic .NET and C#. At first, I assumed that there would be some functional differences between these two languages. However, in time I have come to realize that Visual Basic .NET and C# are equal in terms of productivity, performance, and flexibility. Neither one has a clear advantage over the other.

For example, both Visual Basic .NET and C# provide the syntactic support that’s required to take full advantage of the .NET Framework’s object-oriented programming features. Both languages give you complete access to functionality supplied by the .NET Framework Class Libraries. Therefore, both languages are equally powerful when it comes to building desktop applications, server-side applications, and reusable component library DLLs. Many of the issues that companies had to consider when deciding between Visual Basic 6.0 and C++ simply aren’t relevant issues when trying to decide between Visual Basic .NET and C#.

I have found that the biggest difference between Visual Basic .NET and C# does not involve what you can do with the language. Instead, it involves the syntax and the style with which you write your code. The syntax and style used in each language was designed with distinct target audiences in mind. Visual Basic .NET was created for programmers who have a background with a previous version of Visual Basic. C# was created for programmers who have experience with C, C++, or Java.

You should typically choose between Visual Basic .NET and C# based upon your previous experience with other languages, and based upon your stylistic preferences about how you like to write code. Since I have spent the last ten years writing my code in Visual Basic, Visual Basic .NET appeals to me far more than C#. It’s far more natural for me to write code in Visual Basic .NET because it allows me to leverage my skills and intuitions. For example, when I need to declare variables I am accustomed to using the Dim statement.

Dim i As Integer

								Dim x As Single

Variable declaration in C# is different from Visual Basic .NET. The C# syntax seems backwards to me because it requires that you specify the type name before the variable name.

int i;

								float x;

The chore of programming with an array is another area in which Visual Basic .NET allows me to utilize my existing Visual Basic skills. Let’s say I want to create a string array and dynamically size it with three elements. The Visual Basic .NET syntax is the same as what I am used to.

Dim array1() As String

								ReDim array1(2)
								

								array1(0) = "Mo"

								array1(1) = "Curly"

								array1(2) = "Larry"

I can create a zero-based array in Visual Basic .NET using the ReDim statement, and I can size the array by specifying the upper bound. The equivalent array syntax in C# seems more foreign.

string[] array1;

								array1 = new string[3];

								array1[0] = "Micheal";

								array1[1] = "Janet";

								array1[2] = "Tito";

There is no ReDim statement. Instead, arrays are created using the new operator together with a type name. Furthermore, C# arrays are sized according to the number of elements. This is different from all versions of Visual Basic in which arrays are sized based on the upper bound. Array-based access is also different in C# in that you must use the “[“ and “]” characters instead of the “(“ and “)” characters. I don’t mean to suggest that C# is overly difficult to learn. It’s just that the syntax of C# goes against my intuition.

The code required to enumerate through an array also reveals another fundamental difference between Visual Basic .NET and C#. Visual Basic .NET allows me to write a For loop in the traditional Visual Basic style.

Dim element As Integer

								For element = 0 To (array1.Length - 1)

								   Listbox1.Items.Add(array1(element))

								Next

When using C#, you typically write a For loop using a style that was popularized over two decades ago in the C programming language.

for (int element=0; element<array1.Length; element++)

								{

								   Listbox1.Items.Add(array1[element]);

								}

Most Visual Basic programmers find this C-style syntax harder to read and write. Of course, as a long-time Visual Basic programmer, you might prefer to use a For Each loop instead of a For loop when enumerating through an array to improve your code’s readability. You will be happy to know that Visual Basic .NET continues to support the syntax of the For Each construct for enumeration.

Dim name As String

								For Each name In array1

								   Listbox1.Items.Add(name)

								Next

It is interesting to note that the C# language also provides a For Each construct similar to what’s been available in earlier versions of Visual Basic. The inclusion of For Each syntax in C# is a testament of how the .NET platform as a whole has been influenced by Visual Basic. In addition to the For Each construct, Visual Basic can also be credited for the inclusion of object-oriented programming concepts, such as properties and events in the .NET programming model.

Another reason that I have always enjoyed Visual Basic is that it makes me more productive by hiding certain programming issues. This allows me to concentrate on the application code I am trying to write instead of getting hung up on low-level programming details. For example, Visual Basic has always supplied memory management in a behind-the-scenes fashion since its introduction in the early 1990s. This is one of the reasons why Visual Basic has a reputation of being more productive than C or C++. It is interesting to note that the philosophy of hiding memory management from programmers is now fundamental part of C# as well.

While C# has adopted Visual Basic’s hands-off style of memory management, there are still other areas where Visual Basic .NET adds unique productivity features. One example is that Visual Basic .NET makes it easier to convert between types. Take an example of converting types such as Double and String to an Integer type. Visual Basic allows you to perform all conversions to Integer using the built-in conversion operator CInt.

Dim x As Double = 7

								Dim y As String = “12”

								

								Dim i As Integer = CInt(x)

								Dim j As Integer = CInt(y)

However, C# does not supply the equivalent of the Visual Basic .NET CInt operator. A C# programmer would typically use a C-style cast to convert from a Double to an Integer.

double x = 7;

								int i = (int)x;

However, converting a String to an Integer requires a different technique known as parsing. Therefore, a C# programmer must make an explicit call to Parse method of the System.Int32 class to convert a string value to an integer value.

string y = "12";

								int j = int.Parse(y);

My point is that Visual Basic .NET is able to perform the parsing operation implicitly. Therefore, Visual Basic .NET makes it easier to write your code. All this is made possible because the Visual Basic .NET compiler adds extra instructions into your compiled code to do the same things that C# programmer must write by hand.

I have just provided a simple example in which the Visual Basic .NET compiler adds a degree of productivity over the C# compiler. These are several other areas where the Visual Basic .NET compiler supplies value-added productivity including type conversions, string comparisons, event registration, COM interoperability, and late binding. These productivity features are all good reasons for me to prefer Visual Basic .NET to C#.

Now I must give C# it’s fair due. It’s a very elegant language that is becoming very popular. This is especially true for programmers who have used languages that require semi-colons, curly braces, and case sensitivity. C# supports several interesting features that are not supported by Visual Basic .NET. The most important of these features in my opinion is that C# allows you to write unsafe code. That is, C# allows you to write code that manages and accesses memory directly through the use of pointers.

The use of unsafe code can sometimes be necessary when you need to interoperate with older legacy code written in C. An example of when unsafe code would be required is when you must write low-level Win32 API calls to use a feature of the Windows operating system such as memory mapped files. Therefore, you should see that C#’s ability to support unsafe code gives it an advantage over Visual Basic .NET.

Keep in mind that unsafe code isn’t required in the majority of applications. Unsafe code is not required for interoperability with COM-based code. It is also considered best practice to avoid the use of unsafe code in general application programming. Therefore, I consider C#’s support for unsafe code as a minor advantage over Visual Basic .NET as opposed to a major advantage.

Apart from the ability to write unsafe code blocks, I don’t really miss any C# features that are absent in Visual Basic .NET. That’s because these are features designed for programmers with a background in C or C++. Examples of such features are operator overloading, bit-shifting, and incrementing an integer value using the ++ operator. I say that I don’t miss these features because I have never programmed in C or C++ on a regular basis. Furthermore, these are simply stylistic features that do not allow the programmer to accomplish anything with C# that cannot be done in Visual Basic .NET.

Once again, let me reiterate how you should choose between Visual Basic .NET and C#. You should choose between these two languages based upon your previous experience with other languages. Migrating to C# will be easier for programmers familiar with C, C++, or Java. Migrating to Visual Basic .NET will be easier for programmers familiar with Visual Basic.

There is one last point I want you to consider about choosing between Visual Basic .NET and C#. Sometime the decision about what language to use should not be left to the discretion of individual developers. After all, what if every developer on a team wanted to use a different language? This could easily result in developers on the same team that could not read or work on each other’s code. You can see that a situation such as this has the potential to create serious problems.

In many cases, it’s important to choose a language on a team-wide basis. In less common scenarios, it might even be beneficial to choose a language on a company-wide basis. Having a set of developers standardize on either Visual Basic .NET or standardize on C# can really help to promote consistency.

When a company or team feels there is a benefit on standardizing on a single .NET language, it makes sense to pick a language based on the majority of the developers who are affected by the decision. For example, if 80% of a company’s developers have used C++ and Java in the past, C# would be the best choice for standardization. If 80% of the company’s developers are used to Visual Basic 6, then Visual Basic .NET would be the best choice for standardization. As you can see, a decision to standardize on a specific .NET language will typically force some developers to migrate to a language that was not designed especially for them.

I have been to companies where Visual Basic 6 programmers have successfully migrated to C#. I have also been to companies where Java and C++ developers have successfully migrated to Visual Basic .NET. The transition for these developers is a little harder and there is a tendency for these developers to show a little more resistance during the migration phase. However, the differences in syntax is usually overcome in a matter of weeks or months. But no matter whether Visual Basic .NET or C# is chosen, in the end all these developers are still going to be using a first-class language to write their software.

If you are a Visual Basic 6 developer, I encourage you to take the next step and migrate to Visual Basic .NET. Visual Basic .NET as a language is much more powerful than any previous version of Visual Basic. Visual Basic .NET as a development tool is incredibly enabling because it allows you tap into the full power of the .NET Framework. However, you will also see that migrating to Visual Basic .NET will have its challenges. I can tell you without a doubt, this will take a non-trivial effort on your part.

As I have just mentioned, migrating from Visual Basic 6 to Visual Basic .NET isn’t all that easy. However, there have been rumors in the industry that because Visual Basic .NET is so hard to learn, that Visual basic 6 developers are better off migrating to C#. I just don’t see how anybody that knows all the issues at hand can make such a statement.

It might make sense for a Visual Basic 6 programmer to migrate to C#, if C# were a superior language to Visual Basic .NET. However, C# is not superior, it’s just different. The plain truth is that a Visual Basic 6 developer will have an easier time learning Visual Basic .NET. I know this was the case for me.

I am at a point now where I can comfortably read code in either language. This gives me the ability to inspect code examples written in either language to see how I should accomplish a specific task. However, when it comes time for me to write code, my source files always have a .vb extension.