Coming Soon: Coding Guidelines for VB.NET

In my last post, I forgot to mention the Coding Guidelines for VB.NET that I’ve been working on.

I see a lot of code from many sources as I’m sure all of you are. Every sample, even coming from the same source, uses a different coding style. Which is right, which is wrong? Which should you adopt? Well, these are some very difficult questions to answer. You could purchase the Practical Standards for Visual Basic .NET; however, I found that book to be a complete slap in the face of the Framework Design Guidelines and, honestly, if you use what’s in that book for your code (although it would be consistent), you’d be laughed at by your .NET developer peers. I’m not saying that what’s in that book is wrong per say, just that it isn’t right either. I was very disappointed in that book was basically a rehash of the VB6 edition. And having the following quote didn’t help much either:

“I’ve surveyed a number of developers and trolled many newsgroups, and it seems that most developers plan to continue using Hungarian prefixes because they believe them to be an important part of their development efforts. The good news is that you can continue to use Hungarian notation in your projects and yet still conform to the spirit of the .NET framework design guidelines at the same time. I swear by naming prefixes, and therefore I recommend them as well as use them in this book.”

First things first, this book came out in 2003, shortly after the release of Visual Studio .NET 2002. At that time, the design guidelines weren’t all that well known and people haven’t had a chance to use the development tool and it’s features. So, of course VB developers were still using Hungarian notation. That was about the only way you could determine what a type was in VB6. Very few developers were aware that VS.NET was able to show you the variable type by just moving your mouse over it. Also, the concept of Option Strict On didn’t exist, therefore leading to the need to see variable types because the compiler wouldn’t complain at you for trying to have a Integer (16-bit) set to a value contained in a Long (32-bit).

As for being within the “spirit” of the framework design guidelines? The framework design guidelines are very clear on the subject of Hungarian notation. I was so disappointed when I purchased this book that I pretty much put it up on the shelf and this is the first time that I’ve opened it since I read it the first time.

A few weeks ago I saw a document on Brad Abrams blog that had some coding guidelines for C# that are used internally at Microsoft. They are just guidelines and optional, but at least there’s a document that outlines some sort of consistency. This document doesn’t exist for VB; however, after further research, there are some guidelines used by the VB runtime team, just not a formal document. I’ve taken it upon myself to create such a document using the C# one as a starting point. So far, I would say about 75% of that document has had no changes moving to VB.NET, 25% being changed to fit VB.NET and I’ve added another 40% to it (these numbers are purely a guess).

With this document, I’m taking the opposite viewpoint that James Foxall takes. He came from the VB6 mindset to .NET, I’m taking the .NET mindset to VB. Not everyone is going to agree with these guidelines, which is OK. Notice that I keep referring to it as guidelines, not “standards”. I strongly believe that VB should play nice in the .NET world. My hope is that developers would adopt these guidelines, especially for sample code and demos being shared with everyone else. If that happens, great. If not, maybe it will be the bases of your own guidelines… pick and choose as you see fit. Of course, if you completely ignore it, that’s your choice as well. However, I do want to state that I see it as a living document, one that can be modified based on feedback. I believe in community involvement and, as such, am willing to listen to technical and productivity reasons as to make changes. I’m not writing this document in a vacuum and am getting input from some pretty interesting resources. (If I get permission to use all of their names, I’d be happy to share them as well.)

Anyway, if you are looking forward to such a document, you’ll see it sometime this week.

UPDATE: Released the coding guidelines, you can find them here. For more information about this release, please refer to this post.