What a coincedence!

Just last night, I made a post about my journey into full-time C# use. This morning, I see Eric Gunnerson has mentioned a new magazine called "C# Pro Magazine". I headed over there to check it out and what do I see -- an article titled "5 C# Tips for VB Developers".

I read through the article and was somewhat disappointed. It certainly has a few pointers that will help those who have never done C/Java-style programming. But I have to comment on a few things mentioned in the article.

One key difference between the languages is converting data types. VB.NET is more forgiving when it comes to converting between data types implicitly. For example, VB.NET automatically casts an integer to a string:
Dim i As Integer = 2
Dim s As String
s = i

Uh -- only if you let it. With 'Option Strict On' and 'Option Explicit On' -- which should always be used -- this code is immediately highlighted in the IDE as a problem. And it won't compile either.

This example continues with:

But C# won't even allow this assignment to compile. The compiler yields this error:

Cannot implicitly convert type 'int' to 'string'

This error occurs because C# is a strongly typed language.

Every .NET language is, by nature of running under the CLR, a strongly typed language.

More on converting data types:

C# lacks the convenient data-type conversion functions VB .NET provides, such as CInt, CDate, and CType. These functions ultimately are too forgiving because they let you convert natively incompatible data types, which can lead to obscure bugs in your code.

And the divide operator in C# lets you divide by zero resulting an an Exception. Does that make it a bad thing? No, it means you (the programmer!) need to write code properly. The VB.NET conversion functions are there for backwards compatibility and for convenience. If they aren't the right tool for the job, don't use them.

On optional parameters:

VB .NET also uses method overloading under the hood whenever you use the Optional keyword in a method signature.

No, it doesn't. If you look at the IL for a VB.NET method defined with an optional parameter, there is no overloading going on. The optional parameter is marked with "[opt]". This is just one of those CLR features that is implemented in VB.NET but not in C#. Here's an example:

Private Sub foo(ByVal i As Integer, Optional ByVal x As String = "abc")
If you look at this with ILDASM, you'll see a single signature (no overloading):
.method private static void  foo(int32 i, [opt] string x) cil managed

What the author should have stressed was that optional parameters, while still available in VB.NET, should be avoided and method overloading should be used instead. Why? In the COM world, where many Visual Basic developers will be coming from, optional parameters that are not included in a function call have their default values determined at runtime. In VB.NET, this determination is done at compile time. This is very different and extermely important to realize.

Consider the function 'foo' (defined above) exists in some DLL that our main application references. In COM, if my main app calls foo as:

The optional "x" parameter will default to "abc" at the time the method is executing. In VB.NET, the same call will result in the compiler resolving the default value during compile and actually making the call as:
foo(23, "abc")

The "gotcha" comes when you re-code the DLL with a new optional value. In COM, no problem, just replace the DLL (forget about all that COM registration stuff for now). The main application can remain untouched. In .NET, you'll have to recompile the main application for it to get the new value. With method overloading, you won't have this issue.

All in all, not a bad article, but definitely shows some bias against VB.NET. Phrases like "you'll find the C# syntax to be more efficient" and "VB .NET syntax starts to feel wordy and cumbersome" are one man's opinion and do nothing to help a VB.NET developer become more familiar with C#.


  • > With 'Option Strict On' and 'Option Explicit On' --

    > which should always be used -- this code is immediately

    > highlighted in the IDE as a problem. And it won't compile

    > either.

    Patrick: I agree that Option Explicit should always be used and Option Strict should be used unless you need late binding. But, to be fair, they are Off by default, so it's not altogether unreasonable for the author to make that assumption. VB.NET programmers who know enough to turn them on also know enough to disregard those aspects of this article that do not apply to them.

    In the interest of completeness, however, the author should have mentioned Options Strict and Explicit, and explained that they make VB.NET's behavior more C#-like.

  • In VB.NET, I'm pretty sure Option Explicit is on by default.

  • Phil -- very true. Thanks for the feedback. Although I still think, even when needing late binding, Option Strict should be on. Maybe I'm just a CLR-purist, but I would rather make the reflection calls myself (and know exactly what's going on), then to rely on the compiler to create them for me.

  • Actually, the optional values were compiled into the call site in VB6, too. You can verify this by building an application against a library with an optional value and then changing the library (ignoring the binary compat warning, of course).

Comments have been disabled for this content.