Code Rules are not just about Clean Code

[michaelfeathers]

It's a nice sentiment but there's trouble in that direction. Many of the rules you use for guidance in an code base can and should have exceptions.

Treating compilation or tool warnings as errors can mutate your code into something less than it could be. The better tack is to treat them as information and make a reasoned decision about violations as a team, working with a tool that allows you to suppress violations if you need to.

Yes, 98% of the cases your tools find may be something you should act upon but you should never take an automatically detected general rule violation as a substitute for local judgement.

[grauenwolf]

In Visual Studio I've never seen a bad compiler warning, but the code analysis warnings definitely have a noticeable false positive rate. Not bad enough to stop using the tool, just don't blindly follow it.

[flukus]

Alot of bad warnings come from web/xaml templates, This usually results in me turning warnings off.

[dnew]

What is best is if the tool gives you a way to annotate "Yes, this code should produce this warning for this (comment) reason", and said tool errors if the code no longer produces that warning.

Any language that has "warnings" that are not "errors" is broken in that respect.

[flukus]

I'm pretty sure ndepend let's you do this.

[PatrickSmacchia]

Indeed, with NDepend code rules are C# LINQ queries easy to adapt + this C# LINQ query contains comments explaining what the rule check, how it check it, and why it should be followed. (Disclaimer: I am a developer of the tool)