When using different kind of code metrics it is important to understand that the actual numbers are almost never the main point. Code metrics should be used to see trends and areas of interest not as absolute goals. The numbers should be the catalyst for reaching the business goal. Sometimes the absolute numbers will lead you to miss the actual business goal.
In my previous post I talked about “The Boy Scout Rule”. An easy way to measure adherence to “The Boy Scout Rule” for the amount of code with unit tests are the code coverage metric. The actual test coverage number tells you what lines of code has been covered by unit tests and that is all and well. But more interesting is if you are increasing or decreasing code coverage between check-ins. High code coverage is in general good (to a point) but the more important is your goal to continuously increase that code coverage(to a point) for every check-in and not going the other way around.
Another interesting code metric is Cyclomatic complexity. In short it measures the number of paths thru a piece of code. You can use this code metric to locate methods and classes in you code base that are probably complex and therefore is harder to maintain and could be candidates for refactoring. Use Cyclomatic complexity to remove accidental complexity from you code base. The problem thou is that complexity is not always accidental but inherent to the problem you try to solve so you can’t use absolute numbers when using Cyclomatic complexity. Aggregating the Cyclomatic complexity and trending it over time and you can see if you are a good complexity reduction boy scout or not.
There are lots of other interesting code metrics that you can use and a tool I really like is nDepend. There are lots of different built in metrics and you can create your own using CQL (SQL for code).
One big problem I find in most .Net code bases are the amount of business logic in the code behind classes for WinForms and WebForms applications. It is not always easy to make developers change their coding behavior especially if they have a large code base with this problem. You can try to explain all the problems with this coding style and the benefits of separating the presentation code from the business logic. You will probably fail. I think a better way is to slowly coach the developers using code metrics and good examples.
If you have nDepend you can easily add a CQL query to you build that gives you the classes that has the most lines of code in the code behind.
SELECT TYPES WHERE
DepthOfDeriveFrom "System.Windows.Forms.UserControl" > 0
OR DepthOfDeriveFrom "System.Windows.Forms.Form" > 0
AND NbLinesOfCode > 200
ORDER BY NbLinesOfCode DESC