This still seems to be a problem five six years later.
Clearly, the scanner must be able to work out the cyclomatic complexity of a function, but we seem to be unable to extract that information. Why? This metric is simply not interesting when summed up for a module.
In my case, I do not need a report on which functions exceed the threshold - there are none - but I do need to be able to report the cyclomatic complexity of each function and the average complexity.
Please would you provide a method to extract this from the scanner?
The immediate reason is that we are working to a customer quality model which asks us to report metrics at the function level. However, in the case of the cyclomatic complexity, I don’t really see that it tells you anything except at the functional level.
As your web site says:
The metric is calculated using a control-flow graph formula, helping developers identify overly complex functions that need refactoring.
If you’re not going to report it for individual functions, what is the purpose of the metric?
Yeah, I agree with you here, and numerous academic studies have found that Cyclomatic Complexity generally correlates to LOC. (I’m betting the +1 per method has something to do with that.)
And we simply don’t track any metric at the method/function level. Yes, the rule calculates it, but only for the purpose of knowing whether or not to raise an issue.
If the metric is calculated, it would seem trivial to expose this to the user.
Users will have diverse needs. For many, it is enough to pass the quality gate. Other will need to report measures and metrics even when they are passed. This is such a basic function that it feels unbelievable to find in the second half of a project that it is not there.
Please could you make a commitment to expose metrics/measures to the user at the smallest granularity for which they are calculated?
If the metric were calculated and stored it would be trivial. But only one of those two things is true - and the one that is true is true only when the relevant rules are active in the profile. And adding storage for method-level metrics is definitely non-trivial.