In my last blog I already mentioned the role of software metrics in my graduation assignment. Software metrics are indicators for the quality of the source of a program. For example, one of the most well known metrics is McCabe’s cyclomatic complexity. This metric gives an indication of the complexity of a method or module/class. To calculate this complexity it uses the number of control-flows within this module.
Other well known metrics are described by Chidamber and Kemerer, A Metrics Suite for Object Oriented Design. These metrics can play a great role in source-code reviewing; for instance to give an indication of the classes that will be hard to maintain and understand.

For my assignment I used metrics to evaluate the modularity, encapsulation and complexity of different implementations of the same concurrency functionalities.The modularity, encapsulation and complexity gave an indication of their maintainability.

The fact that more and more tools for software metrics are released and used is a good thing, because evaluating source-code and refactoring the ‘bad’ code can be of great importance for a good evolution of a software product (to keep it maintainable).
But it should not be used as a ‘development method’, lately I see other developers write their code in a way to get optimal results on one or two of these metrics. This is what I would like to call metric driven development and should be avoided. Why ?
Well because software metrics are indicators no more no less, a program for which metrics show good complexity metrics indicates the code is easy to understand, but does not guarantee it !

Software with good metric values can still be ‘bad’. For example, brainlessly refactoring for good metrics might hurt the shared abstraction levels of the methods or their cohesiveness. Which are also important source-code characteristics according to McConnell, and therefore making it doubtful that the refactoring was of any help to the project.

A second reason would be that optimizing code for some metrics will likely hurt the other metrics. For example when minimizing the number of lines of code in a method, one might extract new methods, resulting in a larger amount of methods per object and probably larger amount of lines per class.

So my personal advice would be to use software metrics only in the way they where meant to be: to evaluate a piece of software and to realize that it’s just a tool to indicate software quality not a guarantee.

Popularity: 485 points