Maybe I’ve been unlucky to date, but I’ve yet to see a solution where I can justify the use of StyleCop Analyzers in the backend (or any backend coding style analyzers for that matter). Visual Studio does a pretty good job at building an IDE that encourages us developers to keep our code consistent enough.
For me, StyleCop is too OCD and counterproductive.
Unless your solution requires clean and exportable documentation for a specific purpose, I find that forcing of documentation comments on everything is a bit overkill. E.g. we don’t need to add standard documentation to a boilerplate Main method within the Program.cs file, because if a developer onboarding into the solution doesn’t know the purpose of this method then much bigger problems will occur.
Documentation and comments should be encouraged when needed yes, but not enforced. Your culture should support this relaxed attitude with guidance towards a preferred consistent style, and the right feedback/review processes using PRs and code reviews will do a sufficient job of maintaining consistency.
Fair, StyleCop has its upsides, and I do like the enforcing of consistent spacing and indention. But these problems aren’t going to cause us to lose sleep, probably because my OCD isn’t strong enough for these to be considered serious issues when some solutions/projects have much more important problems such as technical debt.
The use of StyleCop should be low priority and adds an unnecessary overhead to productivity. The ruleset should be a part of the culture, and a refined DevOps process allowing code reviews would analyse any discrepancies. rather than an enforcement.