VB.NET Coding Guidelines

After receiving input from several individuals, I’ve decided to publish the VB.NET Coding Guidelines. I’m not a big fan of coding “standards”, but do subscribe to the idea of trying to keep a little consistency in your coding practices. I’m not going to say that I’m the one-stop answer on the subject; however, I will say that this is a subject that I’ve spoken with many developers and have done a lot of thinking upon. I think we all should follow the Design Guidelines for Class Library Developers. However, these guidelines do not cover language specific details and this is where I hope this document will serve to extend and enhance the design guidelines specifically for VB.NET.

Although I mentioned that I have spoken with many developers on this subject, I should point out that this document was not created in a vacuum. In many cases, some of the guidelines are causing me to have to change several of my coding habits. Some of the information has been gathered by discussing with members of the VB.NET team while the original structure of the document is based on Brad Abrams C# Coding Guidelines which is used internally at Microsoft.

Now, before some people look at this document and scream bloody murder, I need to point out the direction I’m approaching this. First, the design guidelines take priority. Second, I’m looking at the VB.NET language itself, the code designers code generation and the “pretty print” feature within Visual Studio .NET. From there, adding guidelines from my own experience and the experience of others. During this process, I’ve been able to find out some of the guidelines that the Visual Basic .NET runtime team follow. Many of these have been incorporated as well.

Is this document the end all be all for coding guidelines in VB.NET? Probably not. My opinion on coding guidelines is that the document should be as concise as possible, allowing for the whole thing to be absorbed and thus be useful. If the guidelines are too massive or too constricting, they probably will be ignored. Again, these are simply guidelines and should be treated as such.

I would also like to say, as I do with everything else I make available, that I’m looking to improve on this document. Without community buy in, this sort of document may not be as widely accepted as I would hope that it could be. So please feel free to leave comments.

Take me to the VB.NET Coding Guidelines.

UPDATE: Thanks to Marko for suggesting that the link to the guidelines be made available at the top of this post instead of just at the bottom. I’ve made the first mention of the guidelines document a link as well.