Code (or software) metrics are often seen as being so abstract that they are meaningless in the day to day life of a developer. In his blog, Frank Kelly
brings some reality to the abstract concepts of cyclic complexity
, large classes etc. Frank has previously blogged about the usefulness of automated code checkers.
I love the automated code checkers out there, they help confirm my intuition / suspicions about the current state of the code, but the metrics I *really* care (worry!) about are as follows and most of them can't be measured solely from scanning the source code.
The entry focuses on three themes, getting code working, keeping code working, and knowing if the users are happy. Frank writes that getting the code working is about finding bugs and for that task we have tools such as JUnit. In this phase of development he claims that software metrics are not so helpful.
The real value of metrics comes when you are looking at extending and/or maintaining an application. We know what makes code difficult to maintain and we can easily quantify these features in our source code but we (developers) continue to ignore this technology. For example we can scan for classes that are too long, methods that are too long, classes that have too many fields and so on.
Frank concludes that code metrics are "useful for spotting code complexity hot-spots in your source". He also suggests that maybe we should consider a product that can integrate with your source code control system, QA tools and then have the capability to poll users. Sounds pretty dangerous doesn’t it?