StyleCop Check-in Policy updated (v 1.3)

I have updated TFS check-in policy for StyleCop 4.3.3.0 and also compiled a version for TFS 2010 (now that it has RTM’ed).

The sources and MSIs (one for TFS 2008 and one for TFS 2010) are now available at MSDN Code Gallery.

Enjoy!

Mirror from my MSDN blog

Updated StyleCop Checkin Policy (v1.2.1)

After countless nugdes I have updated StyleCop check-in policy for newest build of StyleCop available (4.3.1.3). While at it, I was able to incorporate a few bug fixes and add improvements.

Version 1.2.1 of the policy is available as MSI installer or as zipped source code (available AS IS).

Bugs fixed are:

• Solution containing projects with same Name is not evaluated correctly (keying schema is now by Project VS object instead of Name)
• Same file appearing in different projects causes policy exception
• C# web site projects are now supported

For the last two items, huge thanks to Clement Bouillier for bringing them to my attention.

Additionally, I have added pretty neat feature (in my opinion) to improve the navigation for the errors found by the policy. When policy is evaluated, now any violation found is added both to Checkin dialog and to Visual Studio Error List pane. Thus you can review the violations in the form similar to non-policy StyleCop violations. Additionally, clicking on policy violation either in Checkin window or Error List pane now will bring up the file and the line the violation is found in.

Policy violations are cleared from Error List pane when the policy is re-evaluated or on project build.

If you encounter any issue with the new drop, please make sure to leave a comment (and I promise to handle the issues promptly this time).

And while at StyleCop topick, I’d like to point to an excellent project driven by Howard Van Rooijen – StyleCop integration with ReSharper. If you use both, make sure you get the latest drop from Codeplex.

Related posts:
- StyleCop 4.3 Checkin Policy version 1.2
- StyleCop 4.3 Checkin Policy available
- Get New Version Of StyleCop
- StyleCop Confusion Cleared
- Source Analysis For C# Checkin Policy
- Source Analysis For C#: Custom Rules And More
- Beautify Your Code With Microsoft Source Analysis

StyleCop November news

Just a couple of interesting and very useful articles related to StyleCop.

First, Jason Allor writes about how to gradually integrate StyleCop into legacy projects. The biggest problem with StyleCop (and FxCop for that matter) when you start enforcing rules on legacy projects, is what to do about all legacy code that is not compliant. Well, for StyleCop there is an easy way out (since it operates on source code files) - it is possible to edit C# project file and so all legacy files are ignored during the analysis.

Another interesting project from Howard van Rooijen is integration of StyleCop with ReSharper. Not only it displays StyleCop warnings the same way it does ReSharper warnings, it also provides automated correction options. I am not a big fan of automatic fixes for static code analysis issues (since there should be some thinking involved in most cases), but with StyleCop kind of warnings this is very useful. Not many people fancy removing spaces or changing indentation manually – unless you get paid by the hour that is :)

StyleCop 4.3 Checkin Policy version 1.2

Since the last release of the policy, I have received several comments that required attention, and finally I was able to make changes to the code.

Version 1.2 of the policy is available as MSI installer or as zipped source code (available AS IS), and contains the following new features:

• Ability to import settings from existing *.StyleCop settings file when creating new policy
• Support for VS projects placed under solution folders
• Every StyleCop analysis violation is displayed as separate check-in policy violation; summary window is still available when double clicking the policy violation

Using the occasion, I would like to touch upon some points in policy implementation detail

1. Policy needs Visual Studio to execute, since it makes use of VS extensibility to analyze only the files contained in C# projects in currently opened solution. The idea behind it is as follows: if you have an analysis violation, you should be able to fix that and then compile the code, and that can be done easily only for the current solution
2. Policy supports all flavours of C# projects in VS; I have tested most and am not aware of any unsupported projects at this time. Any feedback welcome!
3. Current version of the policy displays every analysis violation as separate check-in policy failure; however, it does not support easy navigation between policy failure and source code that caused the violation. This is the big must have feature for the next release

And talking about the next release, I am hoping to move source code to CodePlex, so it would be more easily available for modifications. Right now, if you have patches be welcome to send them in.

Related posts:
- StyleCo 4.3 Checkin Policy available
- Get New Version Of StyleCop
- StyleCop Confusion Cleared
- Source Analysis For C# Checkin Policy
- Source Analysis For C#: Custom Rules And More
- Beautify Your Code With Microsoft Source Analysis

StyleCop 4.3 Checkin Policy available

In addition to recent release of StyleCop 4.3, Jason Allor has just released the documentation for extending StyleCop with custom rules (aka StyleCop SDK). CHM file contains information on writing custom rules, integration of StyleCop into build process and API reference.

Since new version of StyleCop includes many bug fixes as well as new rules and in the spirit of documented SDK available, I have updated the check-in policy for StyleCop 4.3. The changes include mostly namespace changes (to StyleCop from SourceAnalysis) as well as couple of fixes.

Please note that version 1.1 of policy is not compatible with the previous version; you will have to uninstall old version and reconfigure the Team Projects accordingly.

You can get either MSI installer or the source code. Both the compiled version and source code are provided AS IS with no warranties of any kind.

Related posts:
- Get New Version Of StyleCop
- StyleCop Confusion Cleared
- Source Analysis For C# Checkin Policy
- Source Analysis For C#: Custom Rules And More
- Beautify Your Code With Microsoft Source Analysis

StyleCop confusion cleared

As Brian Harry and Jason Allor blog about how easy series of misunderstandings may give birth to conspiration theories, I thought I’d drive some of the points they raise home and talk about what’s common and what’s different between FxCop (and Team System Static Code Analysis at that) and StyleCop.

1. FxCop runs on .NET binaries (thus your code must pass compilation) and does not require source code; StyleCop runs solely on C# source files. Thus while FxCop essentially works for any .NET assembly, StyleCop is limited to C# source files (and essentially, this files may not even compile)
2. Team System Static Code Analysis is integrated into Visual Studio project properties, has standard check-in policy and analysis results can be published to TFS data warehouse and as such are reportable. StyleCop is out-of-band tool with limited integration to Visual Studio (very similar to FxCop stand-alone executable)
3. FxCop supports analysis suppression attributes (on element or module level); StyleCop does not.
4. Team System Static Code Analysis product is actively developed as part of next version of Visual Studio (“Rosario”); StyleCop most probably will always be unsupported tool with limited dedicated development
5. And finally, the biggest difference – while StyleCop verifies source code and documentation formatting for C#, FxCop (and Team System Static Code Analysis) is the tool checking the binaries for conformance to design and development guidelines [while FxCop includes Naming rules, it is just part of its rules inventory].

The only thing one can expect from StyleCop analysis is more maintainable code (since source code becomes more uniform and compliant to coding standards). From using FxCop analysis one may expect actual improvement of the code by elimination of design/development flaws as well as making code compliant to common naming conventions.

The overlap between two tools is minimal – here is the table of StyleCop rules that also exist in FxCop:

Rule ID	Rule Name
SA1401	FieldsMustBePrivate
SA1300	ElementMustBeginWithUpperCaseLetter
SA1301	ElementMustBeginWithUpperCaseLetter
SA1302	InterfaceNamesMustBeginWithI
SA1303	ConstFieldNamesMustBeginWithUpperCaseLetter
SA1304	NonPrivateReadOnlyFieldsMustBeginWithUpperCaseLetter
SA1305	FieldNamesMustNotUseHungarianNotation
SA1306	FieldNamesMustBeginWithLowerCaseLetter
SA1307	AccessibleFieldsMustBeginWithUpperCaseLetter
SA1308	VariableNamesMustNotBePrefixed
SA1309	FieldNameMustNotBeginWithUnderscore
SA1310	FieldNamesMustNotContainUnderscore

Only other rules that are code-related rather than formatting-related are the following rules:

Rule ID	Rule Name
SA1404	CodeAnalysisSuppressionMustHaveJustification
SA1405	DebugAssertMustProvideMessageText
SA1406	DebugFailMustProvideMessageText

The rest of StyleCop rules deal with C# source code formatting or code comments.

To conclude, FxCop is more about telling you how you ought to do things, while StyleCop is all about how you should format the source code for the things, no matter what is in that source code.

Myself (while I like arguing about code formatting) FxCop is unquestionably has more value. How about you? Does your “mileage” vary?