Previous posts in this series:


Your boss just finished reading a great series of posts on Code Analysis.  You have been asked to go implement it in your code base.  Do I need to go on here?  Well maybe just a little bit.

A Method to the Madness

Why would management want code analysis?  As a development lead on teams, I have found it to be a very promising way to improve the coding standards of the team.  More importantly though, it provides one way to implement processes. In each section I have added a measurement that can start being captured immediately upon implementation.

It is never too late

You might as well get code analysis into your development process going now.  Unless you have hundreds (I mean literally hundreds) of projects in your solution, it can be less than a week to get code analysis running if nowhere else than your continuous build environment.  This is a quick technical debt win, that can get into your next iteration/sprint/whatever you may call it.

Measurement: Evaluate the bugs before code analysis and after code analysis.  It may surprise you. Also, see how long code reviews take after implementing code analysis.

Enforce The Rules

People ignore warnings, but have to do something with errors.  When turning on code analysis, don’t just treat them as warnings unless you have a very mature team that can’t stand warnings in code. When code analysis rules are enforced as errors, an action must be taken to fix the error, either by suppression or otherwise.

Measurement: Capture the number of build breaks on check in due to code analysis rule failures.

Don’t argue about the rule

Just fix it, I have seen time and time again where the “validity” of the rule was argued for hours when it could have been fixed in minutes.  Now there are exceptions to every rule, but at this point it is a conscious decision.

Measurement: Look at the number of suppressions over time in the code base.  Reevaluate these at a retrospective/after action.

A Word to Leadership

Reward the use of code analysis.  To many developers, the implementation of code analysis may be like “policing” the code that they have written.  Encourage them to share ways that they “changed” the code base to satisfy the rule as a best practice.  Listen when they truly believe the rule should be suppressed permanently and document the reasons.  At the end of the day, it is just another tool in the arsenal of good coding practices.

What experiences have you had with management in implementing code analysis rules?