|
|
A Plug for C# From a VB ProgrammerWise Developers Should Learn Both |   | If I am new to .NET, should I learn VB.NET or C#? This question is bantered around the newsgroups ad infinitum and ad nauseum. As a Visual Basic developer for the past 10 years, I was not eager to learn C#. I had resisted squigglies and semicolns for longer than VB has been around, but after developing in .NET since the release of Beta 1, I have learned to appreciate both languages.
There are several reasons for this. First, regardless of what many would say, the two languages, in many respects, are functionally the same. C# and VB.NET are both built on the same Object Model. They just have some syntatical differences, which at first seem annoying, but the more I code in C#, the less time I have to spend thinking about the differences.
Secondly, from a skills marketing standpoint, no one can deny that knowing both languages equally well will make you more marketable. If you are not always looking for a way to make yourself more marketable, then your career in IT will have a ticking time-bomb in it.
Thirdly, being able to program in both languages tends to make you think as a .NET developer rather than a VB or C# developer. That will naturally cause your code to be more reusable and cause you to code in such a manner that your code can be used in DLLS, callable from either language, regardless of the language in which you developed the code for the DLL.
For example, as a VB programmer, Optional parameters are a very useful feature. However, C# does not support the use of Optional parameters. Therefore, I have learned to use Overloaded methods in VB.NET instead of Optional parameters. That allows code that I develop in VB.NET, and place in a DLL, to be called from C# or C++, thus making my code more reusable, and in a sense more portable or usable from other languages.
In programming in both languages, I have gained an appreciation of C#, again, after I got past the squigglies and semicolns. For example, I recently coded a class in VB.NET and decided to write an article for it. I thought I had debugged it sufficiently. I decided to code it in C# also and include the code for both in the article. When I coded a certain method, shown in Figure 1 below, in C#, the compiler presented me with an error, that VB cannot do, and showed me a potential run-time bug. Consider the following code method.
Figure 1 - VB.NET Method With a Bug In It.
Public Overloads Function GetSetting(ByVal AppTitle As String, _
ByVal Settings As String, _
ByVal key As String, _
ByVal keyvalue As String) _
As Object
Dim i As Integer
Dim dr As DataRow
Dim dt As DataTable
If xmlFile.Length = 0 Then SetupXMLFileName(AppTitle)
If ds Is Nothing Then
dt = GetXml(Settings)
If dt Is Nothing Then Return keyvalue
Else
dt = ds.Tables(Settings)
End If
For i = 0 To dt.Rows.Count - 1
dr = dt.Rows(i)
If CStr(dr("Key")) = key Then
Return dr("Value")
End If
Next
' this line of code was not in the method
' until I converted it to C#
Return keyvalue
End Function
|
When I coded the method in C#, line for line from VB.NET, the code was as shown below.
public string GetSetting(string AppTitle, string Settings,
string Key, string KeyValue)
{
DataRow dr;
DataTable dt;
if (xmlFile.Length == 0)
SetupXMLFileName(AppTitle);
if (ds == null)
{
dt = GetXml(Settings);
if (dt == null)
return KeyValue;
}
else
dt = ds.Tables[Settings];
for (int i = 0; i < dt.Rows.Count; i++)<BR>
{
dr = dt.Rows[i];
if ((string) dr["Key"] == Key)
return (string) dr["Value"];
}
// this line of code was not in the method
// until I converted it to C#
//return KeyValue;
}
|
Notice the line commented out at the end of the method. This line was not in the original method because I had converted from the VB.NET method and it had a bug in it. Upon compiling, the C# compiler showed me a run-time bug, at compile time. I received an error that said "not all paths return a value." That was true, because if no Key value mathes in the for loop, the method will not set the proper return value. Therefore, by converting the code to C#, I found a bug at compile time that my testing had not revealed. I got a new appreciation for C#.
In another instance recently, I ran into a bug caused by using late binding that would have been found at compile time in VB.NET, if I had been using Option Strict. I wasn't and I paid for it in debugging time. Had I been using C#, Option Strict is built in and late binding is not allowed.
Do these two examples mean that I am now going to program in C# and forget VB.NET? Not at all! I have gained a proper respect for both languages. I want to use them both, and I want to code like a .NET developer rather than a VB or C# developer. They both have their strengths and I can benefit in many ways by knowing and using both.
|
|
