I came across Stylecop a while ago. This is a plugin for Visual Studio that has a number of features that further analyse code. Taken from their page:
The goal is to define guidelines to enforce consistent style and formatting and help developers avoid common pitfalls and mistakes.
A reasonable goal perhaps, although being a long time resharper user, I was sceptical to begin with. I was right. Stylecop, while it might work in accordance with its guidelines, is a total waste of time and if used, just contributes to technical debt that can’t be removed without disabling Stylecop. Also I have yet to find any of the pitfalls or mistakes, apart from ones that Resharper or the compiler can already catch such as unused or un-initialized variables for example. A bit harsh? Let me explain in the remainder of this post:
My main beef is with the sheer number of comments it makes you add. There are comments on every source file (not a bad thing), comments on every class header, every variable, every method, and if you are programming by interface (you should be), you have to repeat the same comments on the interface definition as well as the method.
One of the reasons I like C# over VB is that it is concise without being cryptic (although remember, any language is cryptic if you don’t know the language). StyleCop totally destroys this, you have as many lines used for comments as you do code (again if you are programming correctly and having small one purpose, one reason to change classes and methods. The code should document itself. Because you are reading code 80% of the time, having to navigate round these comments, and try to make sense of the code that is no longer on one page, is a royal pain.
Think I’m going over the top? Here is what Uncle Bob has to say about comments. Also here is an example of code that is Stylecop Compliant:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
/// /// The login view model /// public class LoginViewModel { /// /// Gets or sets the email /// [Required] [Display(Name = "Email")] [EmailAddress] public string Email {get; set;} ... (on and on ad nauseum) ... } |
Good variable naming removes the need for comments against each variable or property. Not with StyleCop. Also comments have to be maintained along with the code, increasing the number of lines of code. StyleCop views not commenting as more serious than other logical or functional problems with the code, and although it can auto-generate comments, most of what it does is inane, like the example above.
The inventors of StyleCop probably have never heard of new (2009!) technologies like MVC:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
/// <summary> /// Index page /// </summary> /// <returns> /// Index page view /// </returns> public ActionResult Index() { return this.View(); } |
If you think the above is bad, just wait until you have a method with parameters:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
/// <summary> /// GET: /Account/ConfirmEmail /// </summary> /// <param name="userId"> /// The user id. /// </param> /// <param name="code"> /// The code. /// </param> /// <returns> /// The <see cref="Task"/>. /// </returns> [AllowAnonymous] public async Task<ActionResult> ConfirmEmail(string userId, string code) { if (userId == null || code == null) { return this.View("Error"); } var result = await this.UserManager.ConfirmEmailAsync(userId, code); return this.View(result.Succeeded ? "ConfirmEmail" : "Error"); } |
The comments are meaningless and are longer than the method itself!
Due to our reading the code 80% of the time and writing only 20%, its the function that the code performs and being clearly able to see that intent that is important. This can be an important technique also to help prevent bugs because if it’s patently obvious what the code is doing, bugs should be easier to see as well, not hidden behind a whole load of comments.
StyleCop is also funny about spaces, lines, and will not allow the following code:
|
1 2 3 4 5 6 7 |
for loop ... if (i == 10) continue; if (i == 11) break; ... |
You have to put braces round the continue, increasing the number of lines of code by 3! Same for the break although its not allowed to have the break on the same line as the if!
I have come to the conclusion that much of what StyleCop enforces are not helpful and are in effect anti-patterns that make the code worse, not better. I don’t think I need to say any more, apart from to add a warning. If you disagree with everything in this post, ask yourself, is your team one of those teams that pay so much attention to detail, you lose sight of the goal? While you are checking all this stuff in your source files, you are probably not spending anywhere near enough time on the important matters such as application architecture. That’s been my experience with a number of teams I have worked with unfortunately.
If you really want good, clean code, then this is a big step backwards. For those not familiar with OOD, Programming by Interface, Uncle Bob and the SOLID principles, these topics are well worth researching because they will improve your software far more than any pedantic space checking, comment enforcing program will ever do.
There are a number of great videos from Uncle Bob available for a price at https://cleancoders.com/, not yet on Pluralsight unfortunately. Here is an article I chose at Random from my personal wiki that kind of sums it up http://alvinalexander.com/programming/clean-code-quotes-robert-c-martin (although I’m sure you will find better if you look).
If you are a manager and would like an overview of Agile, then The Nature of Software by Development by Ron Jefferies, one of the original founding members of the Agile Manifesto is a good place to start.
So, to summarise, StyleCop is an anti-pattern. Don’t do it! Use Resharper from Jetbrains, which may even improve your C#, because it has loads of features and optimisations built in which I am still finding out about today.
2 Responses to “Stylecop is an Anti-Pattern?”
Immac
You could always modify the rules to not require comments, stylecop is there to enforce the rules you want to enforce, same with the spacing. Stylecop is a tool, you are the one responsible of how you use it, If you did not take the time to review the rules don’t complain that it is doing silly things.
Phil
I worked for a client whose product manager controlled the Stylecop rules… So he could have the code formatted in such a way that was acceptable for him to be able to read it. I didn’t agree with all the rules I thought it was a bit too much over the top. Especially when you consider that the code architecture was pants and the amount of technical debt caused by over tight control of developers was massive. The devs were all ex VB’ers who hadn’t been on a training course in ten years. That apart, I can’t really see the need to be so anal about the code, correct architecture and following agile methodologies are far more important, neither of which this client did.