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) {}

3 comments so far

  1. Ken Granderson on

    While I agree that VB.Net has better keywords than C#, I disagree with your exceptions.

    For the record, I started doing Windows programming in C in 1990, then moved to C++ and Visual Basic by 1994, and have not looked back since. From the late 70’s, I learned and forgot about a dozen languages, including APL, which is the most incomprehensible language I have ever seen due to its liberal use of symbols, which is also the basis of most of my issues with C-style syntax.

    My issue with the C-style syntax is that I believe that is is based on an outdated need to use the bare minimum storage possible for the code, and thus uses punctuation symbols in its syntax, which requires human beings to do a lot of symbol parsing in order to read C-style code.

    VB’s syntax recognizes that storage is more widely available and IDEs are smarter than they used to be, and thus can adopt a more verbose syntax that is (IMO) significantly easier for humans to read than C-style syntax.

    Specifically regarding your exceptions:

    #1: The keywords ‘Sub’ and ‘Function’ immediately inform me whether the method returns a value of not, rather than requiring me to remember that there is no such data type as a ‘void.’ Obvious visual cues like this save me brain CPU cycles better spent understanding the meaning of the code.

    Rather than ‘use the same word/character to do 20 different things,’ ‘Sub’ infers one type of method use, while ‘Function’ infers another.

    Also, VB uses explicit keywords to let you know that a block of code is a Sub/Function/etc, while C-style languages force you to use your brain as a code parser to distinguish between subs, functions, properties, etc.

    This makes it much easier to scan blocks of code that you did not write and more quickly understand what different blocks of code do, as well as makes it much easier to search for different types of code if you do not have VS available.

    #2: ‘AndAlso’ and ‘OrElse’ are necessary to preserve legacy ‘And’ and ‘Or’ functionality. I would say that this was a deficiency with the legacy VB language, which always evaluated both arguments before performing the logical operation. I am sure that someone’s old code would break if the functionality of ‘And’ and ‘Or’ were to change.

    While I am not particularly fond of the terms ‘AndAlso’ and ‘OrElse,’ I do not have any better suggestions, so I accept them.

    I also appreciate ‘IsNot,’ which finally obsoletes the counter-intuitive ‘Not Is’ syntax that I found to be VB’s most clumsy syntactical construct.

    #3: Finally, I would be willing to wager a week’s pay that I can visually find the start and end of nested VB blocks than any C# programmer can find the start and end of nested C# blocks, precisely because Whatever/End Whatever is precise and infinitely easier to spot with the human eye than curly braces, which look the same regardless of the type of code block they are defining, and look a lot like parentheses when you have been up too late.

    Rather than use the curly brace ‘to do 20 different things,’ Ifs are terminated with End Ifs, Whiles with End Whiles, and so on. Again, the VB language makes the job of interpreting the code one step easier, which gives me more neurons for problem-solving rather than code parsing.

    My basic feeling about the syntax differences is that C-style syntax forces you to spend too much time parsing code (oh, the fact that the property does not have a setter means that it is read only), while VB puts the meaning right in front of you (‘ReadOnly Property’).

    Thus, IMO VB makes it harder to write undecipherable code, while C-style syntax almost encourages it via its use of symbols and more generic syntax constructs.

    While a terse syntax made sense 30 years ago, thanks to advances in storage and CPU power and the powerful IDEs that they have spawned, I find no redeeming value in continuing to perpetuate syntax based on an outdated set of requirements, when a more current philosophy of ‘make the syntax as inutitive as possible and build keystroke saving shortcuts into the IDE’ generates (IMO) significantly easier to read and more maintainable code.

  2. hobbit on

    You might want to check your c# examples before posting them. Your strange switch example wouldn’t compile in any version of the c# language.

  3. dskrm bevtx on

    cxgoaf earmu zcmg hgwnj bdmzgyuxa ivzhu nuys


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: