Style enforcement has long been a hotly debated topic. Not only are their arguments over what style a team should standardize on, but also on whether or not there should be a standard style at all. In a move that is sure to add fuel to the flames, Microsoft has released StyleCop, the style enforcement tool they use internally.
StyleCop, also known as Microsoft Source Analysis for C#, is the source code equivalent of FxCop. Like FxCop it was originally used within Microsoft and has grown to the point where Microsoft sees it being useful to others. But unlike FxCop, it is not highly configurable.
The ultimate goal of Source Analysis is to allow you to produce elegant, consistent code that your team members and others who view your code will find highly readable. In order to accomplish this, Source Analysis does not allow its rules to be very configurable. Source Analysis takes a one-size-fits-all approach to code style, layout, and readability rules. It is highly likely that you will not agree with all of the rules and may even find some of the rules annoying at first! However, the majority of teams using this tool within Microsoft have found that after a short adjustment period, they came to appreciate the rules enforced by Source Analysis, and even began to find it difficult to read code not written in this style.
Jason Allor claims the 200 some rules enforced by the tool are compatible with the default settings found in Visual Studio. Unfortunately, he neglected to mention that Visual Studio comes with 6 very different default-setting collections, many of which directly contradict this tool.
The areas it tool covers include,
- Allowed contents of files
- Debugging text
- Formatting of documentation within element headers and file headers
- Layout of elements, statements, expressions, and query clauses
- Line spacing
- Naming of elements, fields and variables
- Placement of curly brackets, parenthesis, square brackets, etc
- Placement of method parameters within method declarations or method calls
- Spacing around keywords and operator symbols
- Standard ordering of elements within a class
- Use of access modifiers
- Use of the built-in types
Running these rules against an empty console application returns 9 errors, 16 if you have "Keep Tabs" turned on. Some of the rules are rather awkward such as requiring "using" directives to be inside of the namespace instead of at the top of the file.
Already there are complaints about the tool's lack of corrective support. Dustin Norman writes,
As someone who just ran this tool on a rather small assembly, I'm kind of overwhelmed at the idea of fixing 561 violations manually when the tool could fix them for me automatically without affecting the semantics of the code.
The age-old debate over tabs vs spaces has come up again, as well as the inability to disable specific rules. Nick Berardi writes,
Are you kidding me. Tabs are not allowed. Use spaces instead. This is a horrible idea, because it throws blocking layout off, if one variable uses 3 spaces and the other uses 4. This there anyway to disable some of the more pointless rules like this tab one.
It would be nice if you were able to disable some of these rules. I know you said they are for the best. But I totally disagree with this tab over spaces. There is no logical reason for it. Except some holy war that has been battled out between developers since Vi first came to market. I would love to run this over my source code, but it blows up because it alerts me about every line that has a tab in it.
Meanwhile Daniel Stolt asks about VB,
This is a very welcome addition to the set of tools available for .NET developers - but why only for C#? Enforcement of code formatting rules is just as sorely needed for VB developers!
Admittedly, the VB code editor has some rudimentary support for automatic formatting when it comes to indentation and spacing around keywords and symbols, but nothing that even comes close to what StyleCop supports.
By the way, I totally agree with "nberardi" [Nick Berardi] on the tabs vs. spaces issue: what is the problem with tabs? Is it somehow an advantage to have to press the arrow key 4-5 times more to get to a given point? Is it somehow an advantage to have to store 4-5 times as many whitespace characters in a source file?
There does seem to be some interest in at least supporting automatic correction, but no timelines were given.