At what point do Stylecop settings stop being useful and start becoming annoying?

Answer 1

This is more of a rant than a question, I think, but I agree with you that:

• over-enforced style rules are a bad thing.

Whilst there should obviously be guidelines for source code formatting, over-prescriptive unbreakable rules lead to unpleasant corner cases. Sticking strictly to the rules in all cases can generate unreadably messy or over-wrapped code.

Coding is a variety of writing, and as such Orwell's Bonus Rule—“Break any of these rules sooner than saying anything outright barbarous​”—needs to apply to coding style guides too.

I am sceptical that automated style enforcement is a good idea, in a team of competent programmers who can set and understand style guides. Automated lints are useful for catching accidental mistakes, but if applied with highly prescriptive laws for code formatting they cannot take account of Orwell's rule. With a strong ruleset, this may force you to write less-maintainable code under the guise of maintainability.

If you've got less-competent coders in your team, whose output is a jumble unless forced into style, then enforcement might be a good idea. (But then you've probably got bigger problems!)

• automated comments are a very bad thing

I hadn't seen GhostDoc before, but I'm actually a little bit shocked.

The very example on their own front page:

/// <summary>
///     Determines the size of the page buffer.
/// </summary>
/// <param name="initialPageBufferSize">
///     Initial size of the page buffer.
/// </param>
/// <returns></returns>
public int determineBufferSize(int initialPageBufferSize) {

is almost the canonical example of a Bad Comment, adding absolutely zero insight into the code it documents. This is absolutely worse than no comment-doc.

All the in-source-doc schemas that followed Javadoc are a little bit suspect at times, since they clutter the source code with material that's often aimed at end-users—a quite different audience to those reading the code. But this is the absolute pits. I can't imagine who thought this was a good idea.

Answer 2

When it takes more time to code around the rule, than what you ever could get back by reduced maintainence.

As you know, fixing a bug takes a lot more time than writing it, so you can still do quite a lot extra work to make the code more robust and maintainable before you reach the threshold.

Answer 3

It's vitally important that code is well written and readable/maintainable, but we use Visual Studio and Resharper's automatic code-formatting helpers for our code, and AtomineerUtils to keep XML documentation comments in a strictly defined and tidy format.

As a result, the main StyleCop rules are irrelevant, as our code always adheres to the important rules "by default". The lesser StyleCop rules tend to be rather too strict for everyday use. (Most of these rules only make tiny, if any, improvements to the quality or readability of code, so we find the cost of adhering to them unacceptable. We allow our programmers a bit of "freedom of expression" - as long as their code is easily readable by others in the team, we don't mind minor variations in coding style). So after evaluating StyleCop I was unable to find any real world benefit.

In contrast we find FXCop very useful, because the problems that it highlights are more than just about minor readability issues - it picks up serious bugs and performance issues from time to time.

Answer 4

StyleCop is a tool. It's not supposed to be perfect out of the box, and it's not supposed to meet everyone's needs.

Personally I say "Yes, it's important" - because when you're running a team of devs, StyleCop helps you ensure that your coding guidelines are being adhered to. That's exactly its purpose: to evaluate coding standards in an automated, measurable, consistent manner. If you don't want the ability to do that in your build process then you're right - it's a waste of time.

You say it yourself: the zero-warnings goal "needs to be against a reasonable StyleCop ruleset." There's no point running any tool with a configuration that doesn't match your needs. If a rule is "annoying" for you then turn it off - but for someone else it might be vitally important.

As to your "does either add value" question: yes. People underestimate the value of consistency. If all of your constructors have the same style of comment, if all the Intellisense for properties in your project have the same structure, it's one less mental hurdle (no matter how small) to deal with. And with tools that automate it, it's at almost zero effort. What's to complain about?