Code complexity and metrics

My name is Vladimir Milev and I am a software engineer at telerik. I would like to talk about code metrics in my first post on the company blog. The r.a.d.controls suite has come a long way and features a lot of components. This has come at a price though – increasing complexity of the code.

Code complexity is measured in different ways, however, the most commonly acclaimed metric is called “Cyclomatic complexity”. It was introduced by Thomas McCabe in 1976, and it measures the number of linearly-independent paths through a program module. The score is determined by the following formula:

• Start with 1 for the straight path through the routine.
• Add 1 for each of the following keywords or their equivalents: if, while, repeat, for, and, or
• Add 1 for each case in a case statement

When results are computed one can use the following table for assessment of the score:

Cyclomatic Complexity	Risk Evaluation
1-10	a simple program, without much risk
11-20	more complex, moderate risk
21-50	complex, high risk program
greater than 50	untestable program (very high risk)

Cyclomatic Complexity is a really good means to objectively identify problems in a very big sample of code and help prioritize the issues in a more holistic way.

The tool we use for analyzing the CC metric of the r.a.d.controls suite is DevMetrics by Anticipating Minds. It has a command-line interface which makes it perfect for automation and produces reports in XML format. The neat thing about is that it also comes bundled with XSL transformation scripts for quick revision of the result data. We plan to tie it with the quality assurance and build process and we are also working on a cool internal business intelligence tool that will help us analyze the variation of the metrics over a period of time (it’s going to be yet another great dogfood experiment for r.a.d.grid, r.a.d.chart, r.a.d.callback and r.a.d.treeview). This way it will be easy to visualize the progress we are making with improving the quality and maintainability of our code.

Even though the complexity scores are subjective at times, they do identify methods that need attention. We made an internal contest for “most complex product of the Year” and the clear champ was r.a.d.tabstrip. The Grand Prize was a solid refactoring session so we are currently actively refactoring the code and reducing the complexity of the product for the next major update.

Code metrics is new to us and we would be grateful if you share your experience and ideas with our team. Do you use code-metrics at your workplace and do they result in tangible benefits for your team?