Introduction
In our last blog posts we’ve been looking at code coverage reports and how to improve code coverage. We’ve been doing on the assumption that fully tested code is good code. While that assumption is true to an extent it’s not the full picture. A 100% coverage score tell us that all the code is visited by at least test, even putting aside that the tests may be flawed or incomplete does this even ensure good quality code. Indeed what is good quality code ? Its more than possible to write a 100 line “God” method that just does everything using various control structures such as “if /else” and “for / do”. It’s entirely possible to make this code functionally correct then fully and properly test it giving it a 100% coverage score . But that doesn’t get round the fact the code is difficult to understand and deal with thus making edits hard. Even if your test highlight inaccuracies and regression your not exactly helping the developer that has to work on the code after you.
How – Code-Metrics
This is where code-metrics step in, using certain key indicators we detect and track “code quality”. Now I’m sure that will have raised a few eyebrows, how can you detect and track something so unquantifiable as quality if its not described purely by functional correctness. First of all this is not an exact science, these are indicators they highlight possible areas to look at they don’t define or guarantee quality. Secondly they’re not boolean, they don’t give you yes or no that’s good quality code, broadly speaking the metrics are calculated and then there is a recommended range that the value should fall in.
Now metrics are a funny game, they seem like a very coarse tool trying to give information on what appears to be a very complex problem but choosing the right ones and interpreting correctly with reference to historic figures provides a surprisingly accurate “health check” of your code-base.
What’s The Plan?
Over the course of this post we’re going to look at using a freeware tool called SourceMonitor to automatically build-up a code-base metrics report for each build triggered by TeamCity. Then in a very similar manner to our coverage reports we’re going to feed these metric valves back into TeamCity for evaluation. Later we’ll look at getting TeamCity graph each of these metrics allowing us a quick per build health check on the code base. Hopefully allowing us to target our “bad” on a per method basis and gradually improve our scores, overtime improving the code quality making it easier to understand and simpler edited which has to be good for everyone.
