VB + C# Adventures (Final Part)

Now that I’ve been using C# continuously for my current project, I can honestly say that I can switch between VB.NET and C# easily.  As I’ve said before, I learned .NET in C# a long time ago and personal projects are done in C#, but most of my production experience has been using VB.NET. 

Do I regret having to use VB.NET?  Not at all, because it’s all about the framework, not the syntax.  I like being able to use both languages and achieve the same outcome.  Of course I can’t say that I know C# inside and out, but I can’t say the same about VB.NET either.  I also feel a sense of pride being able to do more than one language and not complain about it.  I still find it funny when my developer friends say something like “Oh I hate VB.NET.” or “I can program in C# about 3x faster than VB.NET.”

So which language do I prefer?  I have always preferred C# over VB.NET, but I’ve never complained and never will, if I have to use VB.NET for a project.  Sometimes there’s no choice in what language you have to use and knowing both is a useful skill to have.  Maybe one day if we need to develop some kind of math intensive library, F# will be thrown my way :)

VB + C# Adventures (Part 5)

I Miss This

VB definitely makes certain things easier than C#.  This may go back to the whole VB making me lazy thing, but I miss being able to do this and not having to worry about a null reference exception:

...

Dim i As Integer = Len(Trim(SomeString))

...

Note that if the code above were to changed to SomeString.Trim.Length, a null reference exception could occur in either language.

Conversion methods are available in the System.Convert namespace, but in VB you can do the old CBool(SomeObject), CInt(SomeObject), etc.  I’m not saying that using the System.Convert methods are bad or anything, just that I need to get used to certain things. 

 

Style

I’ll be blunt, I hate sloppy code.  I try to be consistent in my style and cleanliness regardless of the language I’m programming in.  I think that C# definitely has more possibilities as far as clean styles go.  For example:

...
if (someCondition)
    DoThis();
...
if (someCondition){
    DoThis();
}
...
if (someCondition)
{
    DoThis();
}
...

I find all three of the above styles readable.  However, given the syntactic flexibility of C#, messiness is just as easy:

...
if (someCondition) DoThis(); if(someOtherCondition) {DoThis();AlsoDoThis();}
int i = 0;

I’ve always hated code that sat on one line, even way back in college when I was learning C/C++.  Sure it can be more succinct, but I find it harder to read.

VB + C# Adventures (Part 4)

Event Handlers

Adding and removing event handlers in VB is pretty straightforward.  I think the syntax, although wordy, lends itself to readability better than its C# counterpart.  In VB for example:

...
AddHandler o.SomeEvent, AddressOf Handler
...
RemoveHandler o.SomeEvent, AddressOf Handler

In C#, you’d have to do the following:

...
o.SomeEvent += new EventHandler(Handler);
...
o.SomeEvent -= new EventHandler(Handler);

Now the thing that struck me as “funny” was the need to create a new EventHandler delegate (or whatever event handler delegate you created) to remove it in the C# syntax…

 

Method Parameters Passed By Reference

Since I’m using methods that pass parameters as reference, you have to use the ref identifier before those parameters in C#.  At first this bugged me because I was so used to not having to do it in VB.  But is it necessarily better not having to identify a reference parameter?  I got to thinking about this and I now think it’s good to have to denote it. 

Why do I think so now?  The intent of a parameter passed by reference is to change the parameter itself (of course this has different implications for value types versus reference types).  This can lead to confusion if you don’t know that the variable that you’re passing in can change.  Requiring the ref identifier alleviates this confusion in my opinion.

VB + C# Adventures (Part 2)

We’re using Visual Studio 2010 so all of my gripes, comparisons, etc will be based on that. 

The biggest thing I noticed right off the bat is in the IDE.  C# Intellisense is kind of clunky compared to its VB counterpart.  I found this kind of weird…

C# Syntax

I’m finding myself using parentheses where I should be using brackets, but it’s rare. 

I miss the With construct that’s in VB.

I sometimes declare my variable name before the type.

Semi-colons…don’t forget those!

Curly-braces galore!

I find the syntax to be a bit more cryptic.

 

VB Syntax

More verbose, but I find it easier to read (this is just personal preference I guess).

Gotta love direct access to My.Settings and My.Resources.

No need to break after every case in Select (Switch) statements.

Delegate parameters need an AddressOf identifier when passing into a method, whereas C# you just pass in the method.

VB + C# Adventures (Part 1)

I’ll be starting a new series documenting my experiences with using VB and C# simultaneously.  This isn’t meant to be a comparison between the languages, but rather just a non-technical (as can be anyway) dump of the things that are going through my head as I use both languages.  I’m sure this has been done before, but this ought to be fun anyway.

Some personal background…

Back when I was in college, I learned C++ as my first language.  Of course there was some minor SPARC assembly (like I really remember any of that…) and later Java as required by whichever classes I was taking.  I had extremely light exposure to VB6 in my senior year in one of my design classes.  We did UML diagrams and we tied it into a VB skeleton with absolutely no requirement to write any code.  I literally wrote zero lines of VB code in that class.

My first professional job was at a mortgage company and the environment was VB6.  It didn’t take long for me to get adjusted, but I found VB6 a little odd as it went against most of the guiding principles I learned in college as to how to write a program.  Anyway, I’m not going to jump onto the “bash VB” train because that train is full…

Since VB6 was on my resume, my proceeding jobs were also related to me using VB6.  I didn’t mind it, but at the same time I wasn’t really learning anything new… I guess you can say that I started getting bored. 

Fast forward to my current job.  When I first started here, I had zero professional experience with .NET.  I’ve always wanted to get into it, but opportunities seemed slim for me given that I had no professional experience in .NET (catch 22…, but it’s worse for game developers).  I did do some studying on my own in C#, but I wasn’t about to lie and say that I had real-world .NET experience.  I was very fortunate to come across a job listing for my current position and also for the fact that Greg gave me a shot.

Jumping from VB6 to VB.NET wasn’t difficult.  I guess it was because I had retained some of the objected-oriented knowledge from college and the syntax between the two wasn’t too different.  I was (and still am) excited to learn something new for a change.  So far, doing things in C# isn’t too difficult for me.  I had some prior experience with C-style syntax already and I know the .NET framework from doing things in VB.NET already.

I feel that a good carpenter can build a great house with any brand of tools you give them.  The same holds true in the case of a good .NET developer (or any developer for that matter).  A good or bad developer will be a good or bad developer regardless of what language they are using.  This is why I really don’t understand the C# snobbery I see a lot of.  Both languages have their pros and cons, but in the end it’s the result that matters.