StyleCop

Having worked in both types of software companies (#1 - those that care about the quality of the code it produces, #2 - those that do not... and preferring the former by some way!), I was pleased to come across StyleCop - a tool that complements FxCop (which analyzes adherence to the Microsoft Design Guidelines for Developing Class Libraries in .NET assemblies) by checking source code for adherence to the coding standard.

Assuming company type #1, as the size of development teams increases with the scale of the project (and hence, the product under development), the importance of having source code developed in a consistent style increases. StyleCop is an invaluable tool in this regard; it checks source code from spacing between code elements to the correctness of documentation (albeit at a fairly rudimentary level). Even better, it allows integration with Visual Studio projects via MSBuild targets, which will force a build failure in the face of source code that falls short of the coding standard.

This does raise some issues for those that differ with Microsoft in the standards they apply; for these StyleCop provides 2 possible options:

1. Customize the StyleCop settings (optionally, writing custom analysis rules)
2. Change your coding standard

I took option #1, by disabling the settings that went against the coding standard - e.g. requiring that fields be defined at the end, methods be organized in order of visibility (as opposed to functionality/having overloads grouped together). StyleCop saves these settings in a Settings.StyleCop file; when analyzing source code, the merged StyleCop settings will be applied to all files in and below the closest folder containing the Settings.StyleCop file.

The merge mentioned above is implemented as follows: StyleCop applies settings from the global default included in the installation through the folder hierarchy, with the lowest level settings file having the highest priority. Hence, it is possible to define settings and override them at the required level of granularity. For example, I have a Settings.StyleCop file at the same level as the .sln file; however, I have another Settings.StyleCop file wherever an override is required (such as in IDE generated code), at a lower level in the source code structure. This also allows applying StyleCop within legacy codebases in areas where new features are being developed, for example.

Thus far, StyleCop is working just fine; a further minor adjustment to development protocol to require zero FxCop and StyleCop warnings when committing source code to version control will hopefully take the development team to the next level of code quality.