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

Type Coloring (+1 C#)

C# colors types differently. This makes it easy to spot the types from methods and properties.

Runtime Editing (+1 VB.Net)

It seems that when running a C# project, you can only edit C# code during runtime.

VB.Net allows editing of any source code.

Go to Definition (+1 VB.Net)

It seems that C#’s “Go to Definition” is incapable of navigating to a VB.Net source file.  Instead, it just takes you to a meta-data version of the file (without source code).

VB.Net does not have a problem navigating to C# code.

Find Definition (+1 VB.Net)

I use find definition quite a bit to quickly jump to a method or property definition.  Just hit F12, and you’re there.  However, C# adds an additional step.  If a method is overloaded, it will pop up a “Find Symbol Results” window, and ask which overload you would like to go to.  VB.Net infers which you would like to go to based on the parameters that are being fed to the method, therefore removing that step.

Creating Blocks (e.g. Classes, Methods, If…Else, etc.) (+10 VB.Net)

Both VB.Net and C# have automation built in when it comes to creating blocks. However, C#’s implentation is quite a bit less robust.

Creating a new block

VB.Net

To Create a new class, method, and property in VB.Net, you could type:

public class TheClass<enter>
public property TheProperty as string<enter>
<down><down><down><down><down><end><enter>
public sub TheMethod<enter>

Result (including important cursor positions):

Public Class TheClass
Public Property As String
Get
|
End Get
Set(ByVal value As String)
|
End Set
Public Sub TheMethod()
|
End Sub
End Class

C#

To Create a new class and method in C#, you could type:

public class TheClass {}<home><enter><up><tab>
public String MyProperty {}<home><enter><up><tab>
get {}<home><enter><up><tab>
<down><enter>
set {}<home><enter><up><tab>
<down><down><down>
public void TheMethod() {}<enter><home><enter><up><tab>

or (using shortcuts)

public class TheClass {}<ctrl-enter>
public String MyProperty {}<ctrl-enter>
get {}<ctrl-enter>
<down><enter>
set {}<ctrl-enter>
<down><down><enter>
public void TheMethod() {}<enter><ctrl-enter>

Result (including important cursor positions):

public class TheClass {
public String MyProperty {
get {
|
}
set {
|
}
}
public void TheMethod() {
|
}
}

C# Inconsistencies

If there is a syntax error (e.g. unclosed block) near the new block, it will not be auto-completed or auto-formatted.

Comparison

Luckily for C#, <ctrl-enter> exists. Otherwise, you would have to type <home><enter><up><tab>. However, it took me a while to find this shortcut and get used to using it.

Without the shortcut, there are 6 extra keys to hit. With the shortcut, there are only 2 extra keys plus a combo key instead of just enter (so 3 extra keys).

On top of the extra keys in C#, you must make sure all the syntax is correct or else auto-complete will not happen.

Auto-formatting of existing blocks

This is where C# really shows its inferiority. Once stuff gets moved around, the only way to get back to standard formatting is to make sure there are no syntax errors and then hit <ctrl-K><ctrl-D>. Well, that or manually move it… but are we using an IDE here or Notepad?

There are lots of reasons this C# will not auto-format your block for you even after hitting <ctrl-K><ctrl-D>. For example, if a previous block is unclosed, or if there is a syntax error somewhere nearby, such as missing a ‘;’ inside the block.

Feelings on the Matter

I find myself constantly hitting <ctrl-k><ctrl-d> (shortcut for format document) while programming in C#, since the formatting of the document becomes non-standard after a bit of editing.

Basically, VB.Net’s philosophy is: auto-format all the time, unless you are talking about a line continuation (using an underscore character).

C#’s philosophy seems to be: auto-format only when finishing a block and there are no syntax errors to speak of nearby.

The C# versus VB.Net debate in a Slightly Different Light (I Hope)

The C# versus Visual Basic.Net debate has been an ongoing one since the inception of the .Net languages.

Let me start off by saying that I am not so much concerned with the language/syntax itself as with how quickly I can finish my project using that language, and how good the code is afterward. I recently read a great quote: “Programmers don’t like to code, they like problem solving.” I could not agree more.
From a purely language/syntactical perspective, I can save you the trouble of reading this and tell you that it’s purely

Dividing Lines Between Member Groups (+1 VB.Net)

VB.Net’s editor has a nice feature that makes it easy to scroll up and down, looking for a method or property. VB.Net will insert a single pixel line between each property, method, and group of fields.

My guess is that C# doesn’t do this because of the more relaxed formatted. However, this isn’t too large an obstacle. With everything else that the C# editor is missing, I’m am guessing that it just didn’t seem important enough.

Syntax Consistency among Class Members (Events, Properties, and Methods)

VB.Net wins hands-down for being consistent in its syntax. Consider these following examples.

First, let me quickly define my terminology. By implicit, I mean the compiler generates code behind the scenes. By explicit, I mean WYSIWYG. The implicit properties you see are actually a proposed C# language change called “Automatic Properties”. You can read about it here.

Consider the following C# event, property, and method cases.

// IMPLICIT
event <type> MyEvent;
<type> MyProperty { get; set; }
// implicit method is not possible

// ABSTRACT
abstract event <type> MyEvent;
abstract <type> MyProperty { get; set; }
abstract <type> MyMethod();

// EXPLICIT
event <type> MyEvent {add{} remove{}}
<type> MyProperty {get{} set{}}
<type> MyMethod() {}

Now consider these VB.Net cases. I have not found what the VB.Net syntax will be for automatic properties, so I am making a best-guess.

// IMPLICIT
Event MyEvent As <type>
Property MyProperty As <type>
// implicit method is not possible

// ABSTRACT
// abstract event not possible
MustOverride Property MyProperty As <type>
MustOverride Function MyMethod As <type>

// EXPLICIT
Custom Event <type> MyEvent : Add…End, Remove…End, Raise…End, End
Property MyProperty As <type> : Get…End, Set…End, End
Function MyMethod As <type> : End

C# Inconsistencies

  1. Event has a keyword, but method and property do not.
  2. Implicit properties has accessors. Implicit event does not.
  3. Abstract property has accessors. Abstract event does not.

VB.Net Inconsistencies

  1. Explicit event requires “Custom” keyword.

Proposal objections

One thing to note is that some have suggested the new Automatic Properties in C# be formatted like this:

property <type> MyProperty;
readonly property <type> MyProperty;

This would change the C# inconsistencies to this:

// IMPLICIT
event <type> MyEvent;
property <type> MyProperty;
// implicit method is not possible

// ABSTRACT
abstract event <type> MyEvent;
abstract <type> MyProperty { get; set; }
abstract <type> MyMethod();

// EXPLICIT
event <type> MyEvent {add{} remove{}}
<type> MyProperty {get{} set{}}
<type> MyMethod() {}

C# Inconsistencies

  1. Event and implicit property have keywords, but method, explicit property, and abstract property do not.
  2. Implicit properties has accessors. Implicit event does not.
  3. Abstract property has accessors. Abstract event does not.

My Suggested Automatic Property Format

I agree that automatic properties should introduce the keyword “property” into the C# language. However, with this change, property should also optionally be allowed in non-automatic property declarations. This would reduce the inconsistencies considerably.

This would change the C# inconsistencies to this:

// IMPLICIT
event <type> MyEvent;
property <type> MyProperty;
// implicit method is not possible

// ABSTRACT
abstract event <type> MyEvent;
abstract property <type> MyProperty;
abstract <type> MyMethod();

// EXPLICIT
event <type> MyEvent {add{} remove{}}
property <type> MyProperty {get{} set{}}
<type> MyMethod() {}

C# Inconsistencies

  1. Event and property have keywords, but method does not.

Syntax (+5 VB.Net)

Hands down, VB.Net has much better keywords than C# does. The problem is that C# gets its syntax from its C++ roots. In turn, C++ gets its syntax from the philosophy that “if you can use the same word/character to do 20 different things then you’ve written a good language.”

The biggest three exceptions are that I like the fact that C# ditches “Sub” and “Function” in favor of a combined approach, and I think the VB.Net AndAlso/OrElse keywords are pretty silly, and biggest of all is that using {} for block logic is much more flexible and quicker than using VB.Net’s “Whatever/End Whatever” syntax.

Here are some specific examples where the VB.Net keywords/syntax is better:

Constructor

VB’s constructor syntax is more intuitive and requires less typing because if the class name changes, there is no need to change the constructor’s name as well.

VB.Net

Sub New()
End Sub

C#

WhateverYourClassNameIs() {
}

Properties (VB.Net is better)

VB.Net

Property MyProperty() As Type : End Property
Default Property MyProperty() As Type : End Property
ReadOnly Property MyProperty() As Type : End Property

C#

Type MyProperty { }
Type MyProperty[] { }
Type MyProperty { get; }

Now before you say, “but C# requires less typing, so that makes it better!”. Take this into account. C# will be adding an “Automatic Property” syntax. However, because of C#’s terseness, the syntax that is being proposed is causing a lot of concern. One of the proposed solutions is to make these C#’s properties look more like VB.Net’s properties (thought I don’t know if the proposers realized this) by adding the “property” and “readonly property” keywords.

Class Modifiers (VB.Net is better)

“MustInherit” versus “abstract”

“NotInheritable” versus “sealed”

“MustOverride” versus “abstract”

“NotOverridable” versus “sealed”

“Overridable” versus “virtual”

If I were to ask you, “What is a sealed?” Your answer could be “A dead Antartic mammal”. If I asked you, “What is a NotOverridable?” You could only reply, “Something that is not overridable. Maybe a broken bridge?” But at least you would be closer.

Selection Statements (VB.Net is better)

The biggest problem I have with C#’s selection statement (switch) is that it requires a “break” keyword in each case. How often do you actually run cases together? Even if you do run them together, VB.Net’s approach of allowing multiple cases to be specified makes more sense.

VB.Net

Select Case someEnumerationValue
Case EnumType.One
Case EnumType.Two, EnumType.Three
Case Else
End Select

C#

switch (someEnumerationValue) {
case 0:
break;
case EnumType.Two:
case EnumType.Three:
break;
default:
break;
}

Method Declaration (C# is better):

VB.Net

Sub MethodName(argument As ArgumentType) : End Sub

Or

Function MethodName(argument As ArgumentType) As MethodType
End Sub

C#

MethodType MethodName(ArgumentType argument) {}

Serialization of Events (+3 C#)

VB.Net implements events differently than C#.  As a result, when a VB.Net object that contains events is serialized, by default, its events are serialized too… along with the objects referenced by these events… along with the events referenced by these object.

A great article explaining this can be found here.

I must admit that a couple years ago, I spent a very, very long time tracking down some memory leaks that were caused by this problem.  Most of the serialization articles I read were using C#, so they did not mention this issue.

The best way I found to counter it is to create custom events on serializable types.  However, this is a lot of extra work, and so the points go to C#.