Archive for the ‘VB.Net versus C#’ Category

Using a self reference in a field declaration (+1 VB.Net)

When declaring a field, C# does not allow you to use the “this” keyword, whereas does VB.Net allow you (though it is called “Me”).

VB.Net

Private _ClassNeedsRef As New ClassNeedsRef (Me)

C#

private ClassNeedsRef _ClassNeedsRef ;

public ClassWithRef() {
    _ClassNeedsRef = new ClassNeedsRef(this);
}

When trying to think of a reason for this, a friend of mine, Robert, suggests that C# may do this for clarity reasons, though this is only a guess.

At first we though that C# may not want to pass an unconstructed reference, but this cannot be the case, since it does allow you to pass the reference in the constructor.

Advertisements

Method Line Size (+1 C#)

C# tends to have shorter method declarations than VB.Net, since Visual Studio will automatically insert a “ByVal” before each argument. They take the same amount of time to type, it is just that more code is automatically added.

Observe the following method declarations:

VB.Net

C#

Comparison

Each method argument in VB.Net has an extra 7 characters.

Event Handlers (+5 VB.Net)

Creating event handlers is a pain in the butt. That is why it is so important for the IDE to do it for you. Here is how it is automatically done in VB.Net and C#.

VB.Net:

In VB.Net, creating an event handler is as easy as selecting the member that has the event and then selecting the event.

C#:

C# also has a shortcut. You can go to the class constructor and type the event reference and then “+=<tab><tab>”.

Comparison:

You can see that automatic event handler code generation is much easier in VB.Net. What you can’t see from the screenshots is how much the background compiling helps in the VB.Net case. In order to generate event handler code in C#, you have to successfully compile first. VB.Net does this compiling in the background, and it does not matter if there are errors in your code.

Finding Event Handlers

So what happens when you need to find an event handler quickly?

VB.Net

C#

Comparison

In VB.Net, the exact sequence can be used again. All members in the file that have events are listed in the drop down, and the events that have handlers are bolded. In C#, you will need to rely on naming conventions, and either do a search for the method name or else find it in the method drop down.

It is possible that just because you find the name in the C# drop down with your predefined naming convention, that does not mean that the event handler was actually created (e.g. the add handler line was taken out of the class constructor or it was remarked to do some debugging, and never uncommented).

Removing Event Handlers

To remove an unneeded event handler, half the work is needed in VB.Net. In VB.Net, you only need to delete the automatically created method. In C#, you need to delete the automatically created method and then go to the constructor and delete the line that you typed.

Region Placement (+.5 VB.Net)

I love regions.  I use them to categorize my class in a way that makes it very quick and easy to find what I am looking for.  Visual Studio 2005 handles regions differently in VB.Net and C#.

The first VB.Net advantage is that regions are left aligned rather than being tabbed alongside code, and are colored differently.  This makes them easier to spot and does not clutter the code as much.

VB.Net:

C#:

 

The second VB.Net advantage is that it will automatically create the end keyword for a region.  This is just another example of VB.Net automatically finishing blocks, and is covered elsewhere.

Type:

#region “Properties”

VB.Net:

#Region “Properties”
#End Region

C#:

#region “Properties”

Imported Namespaces (+2 VB.Net)

In Visual Studio 2005, under the project properties, VB.Net has an “Imported namespaces” section, which allows you to define namespaces used by the entire project.

This means that VB.Net files have far fewer lines because each one does not need to begin with something like:

using System;
using System.Collections;
using System.Collections.Generic;
using System.Diagnostics;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Shapes;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;

Multiply this by the number of files in a project, and you have quite a lot more code.