Coding standards is one of those topics which can easily create endless discussions between developers (Steve McConnell prefers the term religious wars in his famous book Code Complete). Everybody seems to have his/her own preferences and pet peeves when it comes to the lay out of statements and naming of types and variables (not to mention the eternal “tab vs spaces” argument).
All the programming languages that I have worked with have their own guidelines when it comes to coding standards. Or have they? The C language, father of C++, C# and Java languages, has its own share of style variations: Emacs supports half a dozen C coding styles (K&R, BDS, Linux, etc…), and at least a couple C++ modes (Ellemtel, Stroustrup).
While the Java community can refer to a common standard, this doesn’t seem to be the case for C# developers. The guidelines from Philips (pdf) are the ones which one is most often redirected to, but one can hardly call them “official”; Microsoft has also something on the MSDN on naming conventions, but there doesn’t seem to be anything related to code layout (spacing, indentation, etc…).
Whatever the choice, though, only a few would argue that choosing one standard for the team and sticking to it is not of outmost importance to improve readability and ease maintenance for years to come.
Microsoft Style Cop
Enters Style Cop. Style Cop (not to be confused with Fx Cop) is a free Visual Studio plug-in which is released by Microsoft itself. It can be run on a single file or entire project or solutions and reports all the variations to its predefined set of rules for naming conventions, documentation and code layout. To run it on the current file, just right click on the editor and select the corresponding menu item:
This is the output that I got running the tool on the code above:
If you need additional information about how to fix a particular violation, you can right click on a StyleCop warning, select Show Error Help and dig in:
Default settings can be customized to some extent. To do so, right click on a Project from the Solution Explorer to invoke the settings editor:
From the Rules tab you can relax some of the rules or extend or restrict the scope according to the visibility (private/internal/protected/public).
Yes, you can remove the restriction on the Tabs if you want (but you don’t… do you?). You can even support Hungarian Notation if you wish so (God forbids…!!!).
Default settings are applied at a project level and saved in a file named < em>Settings.SourceAnalysis; It might easily become tedious to repeat the same settings over and over (my Visual Studio solutions have typically at least 4 or 5 different projects, and not counting unit tests); luckily the settings are automatically applied to all projects located in the subdirectories of the directory where the file is. Therefore, it usually suffices to move the file in the solution directory; individual projects can ovverride the general settings by providing their own Setting.SourceAnalysis file if needed (I usually do that for the tests projects where I usually omit XML documentation for test fixtures).
On a final note, if you use MSBuild for integration then you can invoke StyleCop every
time the solution is built. If you are interested, you can find all the details
in this MSDN page.