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:
foo(23)
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#.