Monday, June 3, 2013

Why Visual Basic is Better Than C#

10 Reasons Why Visual Basic is Better Than C#

After having converted a whole lot of training materials based on VB.NET into C#, Andy ‘Wise Owl’ Brown decided to write a tongue-in-cheek rant whilst he could still remember the pain-points. 'Convert to VB.NET! You have nothing to lose but your semi-colons! '
Visual Basic is a better programming language than Visual C#. Who says so? This article! Here are 10 reasons why you should always choose VB over C#.

1 – “Rose is a rose is a rose is a rose”

This is a quotation from Gertrude Stein’s 1922 play Geography and Plays. However, the poetry wouldn’t work in C#, because – unforgivably – it’s a cASe-SeNSitIvE language. This is madness!
Before I start ranting, let me just acknowledge that case-sensitivity confers one (and only one) advantage – it makes it easier to name private and public properties:
Writing properties like this means that you can refer to the public Name property, and it’s obvious what the private equivalent will be called (name).
// private version of variableprivate string name = null;public string Name
{
    get
    {
        return txtName.Text;
    
}
    set
    {
        name txtName.Text;
    
}
}
So now we’ve got that out of the way: case-sensitive programming languages make everything else harder. Why, you ask?
  • You keep having to switch between upper and lower case when typing, causing RSI in your poor little fingers as you reach for the inconsiderately located Shift key.
  • You are much more likely to make mistakes - are you sure you meant to type DateOfBirth, or should it have been dateofbirth?
  • When you accidentally leave Caps lock on, it really matters.
The only possible benefit is that you can use more combinations of variable names, that is, you can use more of one of the few infinite resources in this universe…
It doesn’t matter if you disagree with everything else in this article: case-sensitivity alone is sufficient reason to ditch C#!

2 – The Switch clause

Both VB and C# contain a way of testing mutually exclusive possibilities, the Select Case and Switch clauses respectively. Only one of them works properly.
A Visual Basic Select Case clause, returning a description of how old someone is. The age range for a young person is a tad generous, reflecting the age of the author of this article.
A Visual Basic Select Case clause, returning a description of how old someone is. The age range for a young person is a tad generous, reflecting the age of the author of this article.
Select Case AgeEntered

    Case Is 18
        txtVerdict.Text "child"
    
Case Is 50
        txtVerdict.Text "young person"
    
Case Is 65
        txtVerdict.Text "middle-aged"
    
Case Else
        
txtVerdict.Text "elderly"End Select
You can’t do this using Switch in C#, as - astonishingly - it can’t handle relational operators. You have to use an If / Else If clause instead. But even if you could, you’d still have to type in lots of unnecessary Breakstatements:
switch (AgeThreshold{
    case 18 :
        
txtVerdict.Text "child";
        
break;
    
case 50 :
        
txtVerdict.Text "young person";
        
break;
    
case 65 :
        
txtVerdict.Text "middle-aged";
        
break;
    
default:
        txtVerdict.Text "elderly";
        
break;}
 
It’s easy to forget to type in each of these Break statements!

3 – Event-Handling code

This is specific to Visual Studio (I’m using 2010, the latest version). Suppose I want to attach code to anything but the default Click event of a typical button:
Selecting the button
Let’s suppose that I want to attach code to the MouseHover event of this button.
I can do this in Visual Basic without leaving the code window:
a) First choose the object from the drop list.
Attaching the Mousehover code
Choosing the event to code
b)Then choose the event you want to code.
In C# you can’t do this – you have to return to the button’s properties window and choose to show its events:
Selecting the event in C#
You can double-click to attach code to this event for the selected button – but that’s the only simple way to create it for C#.
But it’s even worse than that. If you then rename a control (in this case btnApply) you have to re-associate the event-handler with the renamed control in the properties window (or in the initialisation code, if you can find it). In Visual Basic, of course, you can do all of this in code:
    Private Sub btnApply_Click(ByVal sender As System.Object,
        ByVal e As System.EventArgsHandles btnApply.Click

        MessageBox.Show("Hello")

    End Sub
Globally changebtnApply to the new button’s name in code, and everything will work as before.

4 –Stupid symbols

C# was written by academics. It shows. Consider this table of C# symbols and their VB equivalents:
What you're trying to doC# SymbolVB Equivalent
Test if two conditions are both true&&and
Test if one or other condition is true||or
Test if a condition is not true!not
Concatenate two strings of text+&
Test if a condition is true within an if statement===
Which column looks like it was designed by a real person?

5 – Autocorrection in Visual Basic actually works

IntelliSense works much better for Visual Basic than for Visual C#. Take just one example – creating a write-only property. Let’s start with Visual Basic:
When you press return at the line end…
    WriteOnly Property PersonName As String
        Set(value As String)

        End Set
    End Property
… You get this fully-completed clause.
For C#, the same thing doesn’t happen:
When you press return here, nothing happens (other than a blank line appearing).
This is just one example. I’ve just spent ages transcribing our VB courses into C#, and believe me, there are many, many more!

6 – Lack of supported functions

Here are a couple of functions I use from time to time in VB:
FunctionWhat it does
IsNumericTests if a value can be converted to a number
PMTCalculates the annual mortgage payment for a loan
Great functions, but they don’t exist in C#.

7 – That wretched semi-colon

Why do I have to end every line in C# with a semi-colon? The argument used to be that it avoided the need to use continuation characters in Visual Basic:
MessageBox.Show_
    text:="This article is a bit opinionated"_
    caption:="Message")
You used to have to use an underscore as a continuation character to show incomplete lines of code in VB.
However, as of Visual Basic 2010 you rarely need to do this anymore. Come on, C#: Visual Basic has ditched its line-ending character; why can’t you?(;)
Someone commented on my original (much shorter) blog about this:

    "In a short amount of time you'll type those semi-colons without thinking about it (I even type them when programming in visual basic)."

That’s like saying that you’ll soon get used to not having any matches to light your fire, and you’ll even start rubbing sticks together to start a fire when you finally manage to buy a box!

8 – Arguments and variables

The order of words in a C# variable declaration is wrong. When you introduce someone, you wouldn’t say, “This is my friend who’s a solicitor; he’s called Bob”. So why do you say:
string PersonName "Bob";
To me:
Dim PersonName As String = "Bob"
…is much more logical. I also find the C# method of having to prefix arguments with the word out confusing, particularly as you have to do it both in the called and calling routine.

9 – Strictness

C# is a much fussier language than Visual Basic (even if you turn Option Strict on in Visual Basic, this is still true). “And a good thing, too!”, I hear you cry. Well, maybe. Consider this Visual Basic code:
Enum AgeBand
   Child 18
   Young 30
   MiddleAged 60
   SeniorCitizen 90
End Enum



Select Case 
Age
    Case Is AgeBand.Child
        MessageBox.Show("Child")
    
Case Else
        
MessageBox.Show("Adult")End Select
With Option Strict turned on this shouldn’t really work, as it’s comparing an integer with an enumeration – but VB has the common sense to realise what you want to do.
The equivalent in Visual C# doesn’t work:
A less forgiving language…
What this means is that you end up having to fill your code with messy type conversions:
The simplest way of converting an enumeration to an integer; but why should you have to?
// find out the age enteredint Age Convert.ToInt32(txtAge.Text);if (Age < (intAgeBand.Child) {
    MessageBox.Show("Child");} else {
    MessageBox.Show("Adult");}

10 – Redimensioning arrays

If you want to dynamically change the length of an array in Visual Basic, you can use Redim Preserve. To do the same thing in Visual C#, you have to copy the array, add a value and then copy it back:
The vile, clunky C# method of extending an array.
string[] PartyGuests = new string[2];PartyGuests[0] "Sarah Palin";PartyGuests[1] "Richard Dawkins";// whoops! forgot to invite Mitt

// create a new extended array
string[] tempGuests = new string[PartyGuests.Length + 1];// copy all of the elements from the old array into new oneArray.Copy(PartyGuests,tempGuests,PartyGuests.Length);// add Mitt as last elementtempGuests[PartyGuests.Length] "Mitt Romney";// restore full list into original arrayPartyGuests tempGuests;// check worksforeach (string Guest in PartyGuests{
    System.Diagnostics.Debug.Write(Guest);}
 
This epitomises Visual C# for me. Critics will tell me that:
  • Behind the scenes, the Redim Preserve command does exactly the same thing as the C# code above; and
  • I should be using lists and not arrays anyway.
That’s hardly the point! The point is that - as so often - Visual Basic makes something easier to code than C# does.

Conclusion

So those are my 10 reasons to code in Visual Basic. What are you waiting for, all you C# code-monkeys? Convert all of your code to VB – you have nothing to lose but your semi-colons!

Original post is:https://www.simple-talk.com/dotnet/.net-framework/10-reasons-why-visual-basic-is-better-than-c/

1 comment:

  1. I like to disseminate knowledge that will I've accrued with the year to help enhance team functionality.

    My weblog; SEO收費

    ReplyDelete