Headline: I prefer Microsoft.CodeAnalysis.FxCopAnalyzers over StyleCop.Analyzers.
Why?
Here are the two primary reasons:
- I can use rulesets I’ve used in the past
- I can share a ruleset across many projects for consistency
- Ok… 3. And there are tons of overly restrictive, or at the very least –very different, rules in StyleCop.Analyzeers.
Conventions
I’ll just refer to these as StyleCop and FxCop for this post. FxCop was done in very much the same philosophy as the original FxCop.
Use Existing Rulesets
For almost 10 years now I’ve used either “Microsoft All Rules” (AllRules.ruleset) or “Microsoft Managed Recommended Rules” (ManagedRecommendedRules.ruleset). The first for code projects and the second for test projects (because we like to use unit test names with underscores for readability.).
I could not find a way to use existing rulesets with StyleCop.
I also have read Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Microsoft Windows Development Series) 2nd Edition at least twice. And if you read that you fully understand the reasoning behind all the rules.
Sharing Rules Across Projects
I have one solution with over 30 projects. StyleCop uses a tree structure under the dependencies to select which rules you want. I could not find a way to “Save” that information and then reuse it across different projects.
Where there is not graphical interface like .NET Standard projects for selecting rulesets for static code analysis, you can merely put something like this in your project file (notice line 6):
From .csproj
- <PropertyGroup>
- <TargetFramework>netcoreapp2.0</TargetFramework>
- <Description>Low level library for basic coding.</Description>
- <NeutralLanguage>en-US</NeutralLanguage>
- <Copyright />
- <CodeAnalysisRuleSet>..\..\AllRules.ruleset</CodeAnalysisRuleSet>
- </PropertyGroup>
So it is quite easy to share a common ruleset across projects.
Different Standards?
I won’t belabor the 3rd point… It’s a matter of opinion and I’m sure that there are people putting lots of hours in trying to make the world of coding a better place. But with all the thought that went into Framework Design Guidelines, and then more than a decade of use for these rules, I’m not ready to unleash a new set on existing code bases.
My experience shows that if you change the rules on a code base with 200,000 lines of code you will generate thousands if not 10’s of thousands of code analysis warnings. And at that point, everyone just ignores them and starts to inject some serious ones by comparison.
Steps I Took
- I used NuGet to install Microsoft.CodeAnalysis.FxCopAnalyzers in all my projects.
2. I then unloaded the projects and added the <CodeAnalysisRuleset> line shown above.
3. Then I just ran Code Analysis on the solution and all my warnings (put there on purpose to test) showed up!
Summary
Thank you Microsoft for developing Microsoft.CodeAnalysis.FxCopAnalyzers for .NET Core. It’s not as easy to use as Static Code Analysis in the past, but better than any alternatives I could find.
Since 2008 I’ve participated in many code bases that have zero code analysis warnings (unless suppressed in Source with a valid Justification) when using the Microsoft All Rules. And our code is much better for it. Thanks!
