Aggregate Cyclomatic complexity is meaningless
Recently, there have been a number of hip online discussions regarding code metrics and their associated value. There have been some excellent points made; however, because it’s my bag, I did notice an apparent misunderstanding when it comes to Cyclomatic complexity. This metric only has meaning in the context of a single method. Mentioning that a class has a Cyclomatic complexity of X is essentially useless.
Because Cyclomatic complexity measures pathing in a method, every method has at least a Cyclomatic complexity of 1, right? So, the following getter method has a CCN value of 1:
public Account getAccount(){
return this.account;
}
It’s clear from this boogie method that account is a property of this class. Now imagine that this class has 15 properties and follows the typical getter/setter paradigm for each property and those are the only methods available. That means the class has 30 simple methods, each with a Cyclomatic complexity value of 1. The aggregate value of the class is then 30.
Does this value have any meaning, man? Of course, watching it over time may yield something interesting; however, on its own, as an aggregate value, it is essentially meaningless. 30 for the class means nothing, 30 for a method means something though.
The next time you find yourself reading a copasetic aggregate Cyclomatic complexity value for a class, make sure you understand how many methods the class contains. If the aggregate Cyclomatic complexity value of a class is 200– it shouldn’t raise any red flags until you know the count of methods. What’s more, if you find that the method count is low yet the Cyclomatic complexity value is high, you will almost always find the complexity localized to a method. Right on!
Sunday 07 Jan 2007 | Andy | Code Metrics
[…] The whole point being that if you don’t monitor metrics like Cyclomatic complexity, all of a sudden you could have a problem on your hands, especially when dealing with legacy code. What a great analogy! Jeremy’s posting is an excellent read; however, it’s unclear towards the conclusion if the measured Cyclomatic complexity values are for single methods or classes in the aggregate. […]
I agree that as a measure of class-level complexity, aggregate CC is at best an indicator to take a closer look at some classes.
For controlling class complexity, I prefer to measure the total number of relationships between methods and fields in the class. If the methods themselves are kept to a reasonable CC limit, then this gives a good indication of class-level complexity.
The cyclomatic complexity of a class is meaningless because it is based on the concept of control-flow of a code. Complexity of a class is not measured by cyclomatic complexity rather it is being treated as design and code size complexity. Finding Design complexity of a class is something on which different views exist.So, considering cyclomatic complexity to determine the complexity of a class is actually you are making fool yourself.
Chris- going point regarding measuring relationships in a class. PMD has a few rules around this notion that I’ve found helpful. Once such rule, CouplingBetweenObjects, “attempts to capture all unique Class attributes, local variables, and return types to determine how many objects a class is coupled to.”
Ayaz- right on! I tend to use JavaNCSS, in concert with PMD for determining code size complexities. One thing I have found time and time again is that big code (either a method or a class) usually has a high CC.