I need to have a bleet about some of my experiences converting Vb.Net 7 to C#3.5 and unfortunately to Vb.Net 9 as well. The conversion is for a massive existing Vb.Net solution in .Net1.1 that for various reasons must remain in Vb. In a perfect world redeveloping using new language constructs and in C# would be my preference. The good news is that there are some satellite web services and components that are small enough to justify conversion to C# and to drag the design kicking and screaming into this decade.
The debate rages between C# and Vb.Net fans and usually most people (who actually know what they are talking about) are polarised to one side or the other. I have used both, and for some time, have a slight preference for C#, but also there are some very nice positive aspects to Vb.Net. I coded exclusively in Vb and Vb.Net for about 7 years, and more recently 3 years in C#.
 |
One major asset I have been a fan of in the Vb.Net camp has is good layman readability. I have taken advantage of this repeatedly in the past and used Vb.Net code to show clients and BA's to help explain behaviours etc.
This can also be taken advantage of by learner developers, as the syntax seems a little more approachable and less intimidating than C#.
|
 |
On this subject, a downside is that sometimes Vb's syntax is very ambiguous and difficult to analyse with automated (handcrafted or thirdparty) tools.
C# is often praised for its concise unambiguous syntax; one line of code can only be interpreted one way.
There is an abundance of tools available for C#, and analytical tools are easier to write for C# source code. Vb.net also has tools available, but not as many as C#, and they are a little harder to come by.
|
|
In my personal opinion I like the Vb.Net syntax of generic type modifiers, apart from the excessive use of parenthesis in Vb and the 'Of' keyword. But I do like the 'As' modifier syntax directly after the generic declaration. For example compare these:
Public Sub MethodName(Of T As {Class, New, IDisposable})()
public void MethodName<T>() where T : class, new, IDisposable { }
|
|
Lambdas in C# are really nice. Vb's syntax is simply awful. Compare these:
list.ForEach(Function(x) Process(x))
list.ForEach(x => Process(x));
In actual fact this won't compile in Vb. Unless I'm missing something you cannot write a Lambda action (one that does not return a value) in Vb. Using Lambda actions is very handy for event handling in C# without having to write loads of methods to handle events.
|
|
And in a similar vein, there are no multi-line lambdas in Vb.Net. Stink.
set.All(x => { Process(x); return true; });
I tend to use this syntax a lot (when changing the method to invoke is not an option), on anything other than List<T> where there is no .ForEach method.
|
|
Historically using Vb.Net without turning on Option Explicit has been frowned upon; at least in my circle or contacts. Now with Vb.Net usage of implicitly typed variables is not possible with this on. Which seems odd to me. I need to investigate this further as I thought Option Explicit only prevent implicit casting from one type to another not type inference during declaration. So right now as far as I am aware in my conversions I have not been able to replicate this in Vb:
var results = from x in someList where condition(x) select new {Name = x.ToString(), From = x.GetType().Name};
|
|
This one really made me tear my hair out. It seems you cannot invoke an Action delegate that is stored in property. Consider this:
Public Class Class1
Public Property MyDelegate As Action(Of object)
End Class
Inside some other method...
Public Sub Method1(director as Class1)
director1.MyDelegate(new Object()) ' Will not work
'You must do this...
director1.MyDelegate()(New Object()) 'this will work - but is a very nasty confusing syntax - looks like a method call or array access
'Or
Dim action As Action(Of Object) = director.MyDelegate
action(new Object()) ' this will work to.
End Sub
Annoying! - C# score's another point here for sure.
|
|
The built in support for XML in Vb.Net is quite convenient, if a little weird. Its definitely more concise and readable than C#.
|
|
Auto-Properties quite simply rock. For example:
public class Class1 {
public string MyString {get; set;}
public int MyInteger {get; set;}
}
In comparison to the Vb conversion:
Public Class Class1
Private _myString as String
Private _myInt as Integer
Public Property MyString as String
Get
Return _myString
End Get
End Property
...
|
| I really like Optional method arguments in Vb. It means the number of overloads for a method is reduced, resulting in more concise code. Optional arguments are not support currently in C#, and can only be implemented by implementing an overload.
Public Function Foo(x As Integer, Optional y as Integer = 1) as Integer ...
Note: I believe optional parameters are coming in C# 4.
|
| It has to be said that I hate the excessive use of parenthesis in Vb. You can almost hear the chief Vb designer say if in doubt throw in a bracket. A crazy example of this is Properties that can take arguments! Why?! Whats the difference then between a property and a method? Its commonly accepted that the whole point of a property is a simple state attribute of an object, it should not change state, and should not contain a significant amount of work. C# definitely wins a clarity point here. |
|
I cannot help but like the convenience of in-line Vb dates:
Dim MyDate As Date = #2/29/2008#
Compared to C#
DateTime myDate = new DateTime(2008, 2, 29); // Or
DateTime myDate2 = new DateTime.Parse("2008/2/29");
|
|
C# has array initialisers.
var theList = new List<string>() {"abc", "def", "ghi"};
Vb has no such convenience :-(. Although I believe this is coming in Vb 10.
|
