What StyleCop like tools are there for VB.NET

see also VB.NET Static Code Anaylsis

For better or for worst we now have a VB.NET coding standards document that is based on a C# coding standard as enforced by StyleCop.

For example

• the number of spaces you should put in each side of a “+” sign etc
• all instance Members (fields and methods!) must be access as “me.fieldName”
• all shared members must be accessed as “className.fieldName”

As I tend to think:

If it’s in a requirements document it should be check for by an automatic system

I am looking for (ideally free) tools that will check for that short of rules on VB.NET code, as these are style issues that don’t make it into the compiled output, FxCop is not useful.

(I would personally match rather that we just check for important things like duplicated code and single reasonability for each cl开发者_开发问答ass (so no more multi thousand line classes!), but as I need to keep to the coding standard document I wish to have a tool to help me do so.)

see also Enforcing using the class name whenever a shared member is accessed.

About the bounty.

I am looking for a list of VB.NET code checking tools, with a short summery of what each tool can do and its limitations. If the tools are not free, please include some ideal of cost.

Does anyone have experience using CodeRush/Refactor! or ReSharper with VB.NET to check for this type of coding style issues?

I know of no free source code analysis tools with good VB support. There are, however, at least two commercial tools that may be suitable:

1. submain CodeIt.Right
2. SSW Code Auditor

Personally, I prefer the CodeIt.Right rule authoring mechanism, so I would favour it if considerable custom rule development were planned. However, if you just want to use out-of-the box rules, Code Auditor ships with quite a few more code style rules than CodeIt.Right, most of whose built-in rules target the compiled IL (like FxCop).

The only ones I know of are:

Microsoft's FxCop

Of course, this only operates on compiled assemblies, so doesn't give the same functionality as StyleCop, and certainly won't help with things like naming schemes.

However, the closest thing is:

Aivosto's Project Analyzer v9.0 for Visual Basic, VB.NET and VBA

The full version is not free, but this is the closest thing to StyleCop for VB.NET that I can find.

There have been a number of calls for a VB.NET version of Microsoft's StyleCop, such as those in this thread on the code.msdn.microsoft.com site. That same thread also gives some good insight into why a VB.NET version doesn't exist.

I use ReSharper on a daily basis and I find it fine for both code formatting and for solving naming issues. It allows to configure how naming must be enforced, how issues are displayed (hint, suggestion, warning, etc) and provides a precise code formatter (space, paranthesis, line breaks, this qualifier, etc).

Note that I don't know if it can be run in batch mode.

Turning Option Explicit on by default is always a great idea and should be standard practice. I would argue it should be turned on by default in VS out of the box. But it doesn't come close to enforcing the out of the box rules that StyleCop does for C#, nor does it allow for you to create your own rules.

The whole reason for StyleCop's existence is because FxCop only works on compiled assemblies, leaving web projects out in the cold for a similar tool. With StyleCop, web developers get the same great rule enforcement and tight VS integration. It is a great tool for any C# developer.

It is unfortunate that it is only C# capable, a VB version would satisfy a large community that is left wanting something similar.

There already is a very good style tool built into the VB compiler. It is called Option Explicit On, put it at the top of the source code file or use Tools + Options + Project and Solutions + VB Defaults, Option Explicit = On. If that wasn't turned on previously there could be a mountain of errors when you compile your code after changing that.

If it is clean or already turned on, consider that you are 95% close to writing clean C# code and that the language doesn't really matter anymore.