Or put another way, is VB just C# without semi colons? Well, yes and no. If you work in the big wide world of many different programming languages, frameworks, libraries, and operating systems then C# and VB are so close as to be almost indistinguishable. They both have great support from Visual Studio, they both produce managed code that runs on the CLR, they call the same framework functions, they have keywords for the same CLR concepts, and they both have a community of support, sample code, tutorials and the like. But those communities aren’t twinned – some samples are available only in VB, and others only in C#. For historical reasons there are a lot of C# programmers inside Microsoft, and perhaps that’s why VB samples can be a bit thin on the ground.

This less-than-100%-overlap between the samples, tutorials, and so on for the two languages results in people who are proficient in one language trying to read (or worse, write) in the other. Sometimes a great C# developer will be asked "where’s your VB sample? Quick, translate your C# one right away!". Other times a great VB developer will be trying to write their own VB code while reading samples or tutorials written in C#. It can go in the other directions, too.

But although these two languages have a great deal in common, they are different, and in more than just syntax. There are features in each that aren’t in the other. There are natural idioms, too. Idioms are a way of writing things that are natural to one language or identifiably belong to one language. Choosing an example not from the VB/C# world, but from C++ or C, it used to be just so normal to write

if (p=SomeFuncThatMightReturnNull())
{
//do something that relies on p not being null
}

That’s C++, and a deliberate single equals sign. I am assigning p the return value from the function. Then I am testing that value. (Quibble: I am testing what the = operator returns, which is the value just assigned for all well written = operators.) If it’s not null, we’ll do the stuff in the braces. Sometimes I used to come across this instead:

p=SomeFuncThatMightReturnNull();
if (p)
{
//do something that relies on p not being null
}

Or even

p=SomeFuncThatMightReturnNull();
if (p != null)
{
//do something that relies on p not being null
}

Now these other ways of doing it aren’t wrong, they will compile and work, but they demonstrate a lack of familiarity with C++ idioms, with a C++ way of thinking. They are usually written by people who aren’t very comfortable with pointers.

Similarly, in VB, I have seen more than once this sort of thing:

        Dim retval As Boolean = False
        If x > y Then
            retval = True
        Else
            retval = False
        End If
        Return retval

Again, that’s not wrong exactly, but it’s not what I like to write. I prefer just:

        Return (x > y)

Sometimes people say I write C++ in VB, because that's a very C++ way of writing things. But I find it not just easier to read -- it's less bug-prone. (Copy and paste errors like having True in both clauses, for example, will make you crazy.) I know that it’s kind of a C++-ish way to express myself, but it feels natural to me and it works. People who are less comfortable working with Booleans tend to prefer the first, more verbose way. They can see the whole thing laid out for them. It’s not wrong, just different.

Well, it turns out those who try to write VB when they’re proficient in C# are likely to run into a lot of differences in thinking and expression when they take on that task. It might be syntax tripups, missing the use of a helpful VB feature that isn’t in C#, or just writing code that doesn’t use the VB idioms. Kathleen Dollard has amassed a huge list (77 at the moment) of things you should know if you want to write VB code. Required reading for C# people who have to write VB, entertaining for those who like VB, and what's more, plenty of experienced VB developers could learn a thing or two from it (I did.)

Kate