This project is read-only.

Best practices in fixing StyleCop violations

Apr 21, 2011 at 10:58 PM

It would be great to add one more article to the documentation - Best practices in fixing StyleCop violations - and describe what is the best way to fix StyleCop errors in a large solution. Let say we have a version control system with several branches for the same solution which contains a dozen of projects. Each branch is under active development. Time to time different branches integrate into main. Our goal is to minimize difficulties during integrations.

Should we make changes in one branch only and distribute them to other branches during integration? Or we should make changes in different branches in parallel?

Should we fix file-by-file or project-by-project?

Should we fix rule-by-rule or apply the entire rule set?

Apr 22, 2011 at 10:58 PM

Best practice which I am using.

New Projects

Write your code in a way so that you don't get StyleCop warnings from the very beginning of a project. The code you commit to your source control should contain 0 Errors (always!) and 0 Warnings (if there are warnings write a note in your changelog and/or commit message describing why you committed code even it contains warnings)

Legacy Projects

Run the ExcludeStyleCop utility (e.g. see for a (large) legacy solution. If you touch/change a source code file remove it from the StyleCop exclusion and fix the StyleCop violations. Do a commit with commit message ("code cleanup" or something similar). Then do the "real" coding changes. The two commits will help you to find the real code changes more easily (e.g. if you do code reviews). This approach will avoid that tons of code cleanups are hiding real code changes.

Maybe you consider to use StyleCop via MSBuild. Maybe using FxCop too if you're developing class libraries.

--Harald-René Flasch (aka hfrmobile)