The software industry has a cyclic love-hate relationship with code metrics. At times, metrics appear to be quite helpful and at other times, doubt regarding their efficacy casts a short-lived shadow, which, once gone, the cycle starts over. Because it’s my bag, baby, it appears that closing in on 2009, we’re entering a period of disco-induced code metrics love. In particular, because two interestingly hip blog entries and an innovative open source project suggest simple, yet helpful ways to leverage metrics. First, my friend Erik Doernenburg, posted an interesting entry entitled “How toxic is your code?” in which he suggests utilizing a simple bar chart that measures the toxicity of each class in a code base. Toxicity, in this case, is a function of a particular metric compared to a threshold. For instance, Erik notes that the method length metric has a threshold of 30. If a class contains a method that is longer it gets points proportional to the length of the method in relation to the threshold, e.g. a method with 45 lines of code would get 1.5 points because its length is 1.5 times the threshold. The score for all elements is added up. So, if a class comprises two methods, one that is 45 lines and another that is 60 lines long, the method length component of the score for the class will be 3.5 points.Erik then goes on to list 11 various metrics and their corresponding threshold– indeed, using 11 hip metrics sounds a bit toxic as I’ve found, many metrics are inter-related and thus, cyclomatic complexity, method size, and fan-out are usually adequate indications of issues (that is, should these metrics be large for a class). Nevertheless, the applicability of the metrics he’s listed is easily enough to obtain and Eric’s even included a tiny VBA utility to generate the toxicity chart. James Shore, the author of Oreilly’s The Art of Agile Development, recently wrote an engaging blog entry dubbed “An Approximate Measure of Technical Debt” in which he suggests that one can measure technical debt via lines of code. Accordingly, the more bogue lines of code a code base has, the higher the technical dept conceivably becomes. James asserts that If we define technical debt as high cost of change, then SLOC fits the bill perfectly. Estimation gurus have long known that lines of code are correlated to effort and defects. In fact, many estimation tools work by taking a size estimate (either in lines of code or its language-neutral equivalent, function points), then running it through an algorithm that estimates project length, effort, and cost.Indeed, baby! The fewer lines of code, the better! James goes on to suggest a new metric, Spag, which is a convenient way to count executable lines of code (i.e. “one spag equals 1,000 statements”). His emphasis on executable lines of code is important as it does drastically reduce the overall SLOC metric; for instance, in James’s HelloWorld example, executable code is 1/5 the total SLOC. Lastly, I was recently informed of a fairly captivating open source project dubbed Sonar — it’s a dashboard that reports various metrics over time with snazzy charts and data points. Quality management dashboards aren’t new and frankly, from my experience, it appears few teams actually use them (and believe me when I say even fewer teams will buy them!); nevertheless, this is another attempt at capturing a user base. Currently, Sonar requires the project you wish to monitor be built using Maven 2, which is bound to scare off a large portion of the population; however, I’m betting eventually they’ll provide some Ant targets to facilitate adoption. They’ve even provided a Hudson plug-in! All in all, code metrics are what you make of them — they can be useful and they can also be meaningless. Applying them in simple and innovative ways can unveil a whole new world of meaning and ultimately help you manage and maintain a code base more effectively. You can follow thediscoblog on Twitter now! Open Source