Leaning Into Windows - All Comments

re: What a C# Coder Should Know Before They Write VB

Kathleen — Thu, 24 Jul 2008 17:09:04 GMT

Note to self (visible so you know I will include it)

Provide a bullet on symbolic operators

re: What a C# Coder Should Know Before They Write VB

Kathleen — Thu, 24 Jul 2008 17:08:07 GMT

Int 19H,

So, you have to couple your business logic to Sharepoint? I feel for you having to use Sharepoint at all.

Kathleen

re: What a C# Coder Should Know Before They Write VB

int19h — Thu, 24 Jul 2008 08:19:13 GMT

> VB doesn't require (or permit, as far as I know) the callsite declarations required by C# for ref/out parameters. This also effectively eliminates the distinction between ref and out parameters because the stronger definite assignment rules for out parameters aren't checked.

Since VB always initializes locals to their default values, it doesn't bother with definite assignment rules at all. And of course you can apply InAttribute and OutAttribute directly for other cases where they matter.

re: What a C# Coder Should Know Before They Write VB

int19h — Thu, 24 Jul 2008 08:10:03 GMT

> What do you mean by "overly verbose"? You mean you hate the "Function" keword?

Well, yes. I think that part of the reason for lambdas is that they should be short and concise - something that I feel the VB syntax is lacking at the moment. The one the C# guys came up with is pure genius (and reminds me fondly of Haskell, where it is obviously shamelessly borrowed from ;).

> As for XML literals, this seems like such a non-issue. If you are doing XLinq, XML literals or text processing - isn't it to a specific schema. If so, do you really want it in your main body of code?

I have the misfortune to code for SharePoint, and so my code is often littered with parametrized CAML query fragments. Building them by directly by invoking XElement constructors is too verbose for my liking, and using literal strings with formatting placeholders is brittle because of the need to escape everything properly. Proper XML literals would really help there.

And yes, it is part of the business logic processing, so refactoring a specific query to a separate assembly doesn't sound like a good idea to me.

re: What a C# Coder Should Know Before They Write VB

Hector — Thu, 24 Jul 2008 06:42:34 GMT

Those string functions are there just for retrocompatibility... and I wouldn't use them. The proper way of doing this would be using the native .NET methods. The same goes for the exit keywords... better to use the return statement...

Some things that maybe should be mentioned as well are: VB supports optional parameters, although a lot of people consider overloading the right way, VB doesn't have unsafe blocks, stackalloc, etc. Also, I think VB uses a different model thread appartment, but not sure on this one, and maybe the My spacename could be named as well, although a lot of people is against it. There are also the application events at design time, saving settings on exit, chosing if the application is single instance...

re: What a C# Coder Should Know Before They Write VB

Kalpesh — Wed, 23 Jul 2008 23:32:24 GMT

Hi Kathleen,

Very well coverage.

You might add the following, if not added already.

use of paramArray (VB), params (c#) for variable number of arguments.

Exit Sub/Function (VB), return/return X (c#)

Exit Do/For (VB), break; (C#)

Me (VB), this (c#)

len(myString) (VB) and myString.Length (c#)

and other string related functions such as Mid, Substring, Right, Left

re: What a C# Coder Should Know Before They Write VB

Kathleen — Wed, 23 Jul 2008 14:47:21 GMT

Int19H,

What do you mean by "overly verbose"? You mean you hate the "Function" keword? Or do you mean the backflips you need to do to accoplish a proper closure in a multi-line lambda.

Iterators are a problem and I think the lack of multi-line lambdas are a real issue.

To be clear, the purpose of this post is not to convert anyone - those battles aren't meaningful. The goal is to provide some detailed information to help anyoen crossing over.

As for XML literals, this seems like such a non-issue. If you are doing XLinq, XML literals or text processing - isn't it to a specific schema. If so, do you really want it in your main body of code? If its in a separate wrapper assembly anyway (where I think it belongs) who cares what the base language in that assembly is? Wrappers are simple and using VB ensures they are isolated.

Thanks to you and everyone else that commented on this version. I am updating it per these comments.

re: What a C# Coder Should Know Before They Write VB

Douglas McClean — Wed, 23 Jul 2008 14:05:55 GMT

One more to consider:

VB doesn't require (or permit, as far as I know) the callsite declarations required by C# for ref/out parameters. This also effectively eliminates the distinction between ref and out parameters because the stronger definite assignment rules for out parameters aren't checked.

re: What a C# Coder Should Know Before They Write VB

Eric — Wed, 23 Jul 2008 11:30:10 GMT

Kathleen,

Nice list... Appreciate your effort. There is a slight mistake in #26, the correct C# code is:

var list2 = new List<string>() { "Bill", "Percy" };

foreach (var k in list2) {

// do something

}

"k" must be declared, either explicitly or via type inference. In this clip k is correctly inferred to be of type string.

-e

What a C# Coder Should Know Before They Write VB

DotNetKicks.com — Wed, 23 Jul 2008 11:27:44 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: Casting and Converting in Visual Basic

int19h — Wed, 23 Jul 2008 11:05:46 GMT

> The C# parentheses style cast does an implicit widening cast

No, it does not - it does an explicit widening cast, by definition (since the cast is explicit in the code!).

What you probably meant there is that C# cast operator does both proper casts, and value conversions.

re: What a C# Coder Should Know Before They Write VB

int19h — Wed, 23 Jul 2008 11:01:45 GMT

#26 is actually incorrect - you absolutely can infer type of variable in foreach loop in C#, you just need to tell it to do so explicitly using "var":

var list2 = new List<string>() { "Bill", "Percy", "Fred","George", "Ron" };

foreach (var k in list2)

{

// do something

}

#27 misses the fact that neither pre- nor the postcondition is required on a Do-Loop statement (but then MSDN misses it too). This means that VB actually has a dedicated construct for "endless loops", similar to C# "for(;;)". Actually, Do-Loop is probably the best VB statement, considering how neatly it covers all possible options with syntax that makes the exact behavior of the loop very clear.

Then again, the lack of iterators and overly verbose lambdas are the dealbreakers for me. Iterators especially are a necessity in the LINQ age. So I'll stick with C# for now... but I sure hope we get those XML literals, too.

What a C# coder should know before moving to VB

Goto 100 - Development with Visual Basic — Wed, 23 Jul 2008 10:23:16 GMT

I am one of those C# coders moving to VB that Kathleen is thinking about in her post on What a C# Coder

re: What a C# Coder Should Know Before They Write VB

Kathleen — Wed, 23 Jul 2008 03:20:42 GMT

Steve,

You're right. I actually started this list thinking I'd take an hour and jot down a few things and it grew!

I'll look at adding clarity to the list, particularly the parts you point out.

Kathleen

re: What a C# Coder Should Know Before They Write VB

Kathleen — Wed, 23 Jul 2008 03:19:31 GMT

NotMyself,

(Sorry I don't have a better name for you)

Thanks for bringing this up. It was definitely in my brain at one point, but it fell out prior to making the page.

You are incorrect about the lack of ternary operator. In VB 9 (.NET 3.5) VB got a true ternary operator which is the operator version of If. I'll add an example, but

x = If(whatever, isTrueValue, isFalseValue)

this is a true ternary - the boolean condition (whatever) and the return value (isTrueValue OR isFalseValue) is evaluated. The other value is NOT evaluated. This is not a method call, but a true ternary.

VB also got

x = If(whatever, defaultValue)

in this case, if whatever is not null/Nothing it is returned. Otherwise the defaultValue is used.

You are correct that IIf is fatally flawed and should not be used - espicially in VB 9 and beyond.

Thanks for the comment and I'll include that in the next rev of the post.

Kathleen

re: What a C# Coder Should Know Before They Write VB

Steve Smith — Wed, 23 Jul 2008 00:53:41 GMT

Hi Kathleen, very nice list. There were a few points where an example would clarify things, I think. For instance, #5... what would this do for me?

#26 Can you show an example where this would matter?

#13 would benefit from an example showing two statements with/without select and how they're equivalent, I think.

#27 again a quick example (a link to one would do here) would be handy for some, I think.

re: What a C# Coder Should Know Before They Write VB

NotMyself — Wed, 23 Jul 2008 00:29:28 GMT

Kat,

The biggest thing I had to get used to in switching from C# to VB was trinary operator...

IIf Is Not ?:

In C# ?: is a simple way to write if/else statements.

In VB.NET IIF actually executes both blocks of code and returns what ever the correct one is.. this caused me no end of problems until I looked it up.

re: What a C# Coder Should Know Before They Write VB

Kathleen — Tue, 22 Jul 2008 19:34:49 GMT

Bill,

I'm updating it as we speak :)

Yeah, we can try to talk Patrick into it ;)

Kathleen

re: What a C# Coder Should Know Before They Write VB

Bill Wagner — Tue, 22 Jul 2008 18:41:27 GMT

Kathleen,

This was a great post. And, it gives me an idea: Do you think Patrick Meader would go for a couple articles where you and I wrote the same algorithms idiomatically in C# & VB.NET? We could explain the differences, and why each language took that path.

Let me know what you think: bill.wagner@srtsolutions.com

Dew Drop - July 22, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - July 22, 2008 | Alvin Ashcraft's Morning Dew — Tue, 22 Jul 2008 12:00:05 GMT

Pingback from Dew Drop - July 22, 2008 | Alvin Ashcraft's Morning Dew