Really nice tips!

will try to keep it in my mind

thanks!

I have been aware of the CRAP metric for a while now but have only taken a cursory look, and therefore have not formulated an opinion on the subject. However, I have seen organizations obtain value from the McCabe cyclomatic complexity metric, not only on its own but also in conjunction with other metrics. For example, metrics such as one which gives the ratio of cyclomatic complexity to SLOC, the essential density (ratio of unstructured paths to cyclomatic), the design complexity (cyclomatic paths related to calls to other modules), and others.

Cyclomatic complexity measures control flow. The reason why case and switch statements add to cyclomatic complexity is because you do indeed need to test the control flow associated with the case and switch statements.

However, the one acknowledged exception to limiting the cyclomatic complexity to ten (10) are modules that include a switch or case statement (some can be very large). If you have perfectly structured switch and case statements (and also avoid jumping into loops/decisions and out of loops/decisions within the rest of the logic) the McCabe essential complexity will always be one (1) indicating a perfectly well structured module. McCabe essential complexity is bounded by the cyclomatic complexity and guides in modularizing or partitioning high cyclomatic modules into smaller more understandable pieces.

Frequently, software engineers obtain cyclomatic complexity values to understand the complexity level, but do not then use it as part of the total Structured Testing Methodology as described in the NIST document (http://www.mccabe.com/iq_research_nist.htm). Being cognizant of cyclomatic paths enables one to catch errors that deal with the interactions of code constructs, which results in higher reliability. Some of the bloggers are hitting on this thought - that the cyclomatic complexity (even as it is incremented for all outcomes of a switch outcome) can at least help you be aware of all paths, so you can make more informed decisions about your testing effort. More info on this subject can be at

http://www.mccabe.com/iq_research_appNotes_1.htm.

Peace
-stephan

Your view is valid though I think. Different, but equivalent code, has different CCNs.

case 1: lowerTemperature(3); break;
case 2: lowerTemperature(2); break;

has a higher CCN than (Simple doItYourself Java rule engine):

on(1).adjust(lowerTemperature(3));
on(2).adjust(lowerTemperature(2));

although both fragments do the same and perhaps, have the same complexity.

Peace
-stephan

Moreover, up to a CCN of 25 or so, there is no correlation between CCN and bug frequency. A higher CCN value has equal probability of matching higher or lower bug counts in that range.

And since my experience is that the *vast* majority of Java methods have CCN of < 25, I think it’s more accurate to say that for the majority of Java code, CCN in fact is not a useful predictor of quality–nor of how many unit tests you should be writing. Above 25, as you state in the original post, CCN does correlate to an increasing bugginess.

And since my experience is that the vast majority of Java methods have CCN of < 25, I think it’s more accurate to say that for the majority of Java code, CCN in fact is not a useful indicator of quality–nor of how many unit tests you should be writing.

“..that amount of complexity *may not be enough to say the code is buggy…”

Our follow up blog to the video we posted on different peoples views, proves that it is indeed probable that, knowing nothing else about a file, having a higher McCabe value is enough to be fault-prone.

Of course nothing in this industry is certain…

Anyhow, it would be more fun to have this dialogue over a beer. (I’ll be at CITcon and JavaOne.) My original point is that CCR’s measure of complexity is flawed in how it counts switch statements. Simple case statements are surely less complex that the equivalent number of if/else statements, so I think they should have a lower level of complexity.

Handed a method with over 30 branch points *is* a problem. Even if you test every line 100% (which CRAP takes into account) the sheer amount of branch points means:

1) A huge number of test cases to hit 100% line & branch coverage
2) A high amount of refactoring if the the assumption this code is based on changes

The metric here would say, high complexity with 100% test coverage… ok so far so good. Then it says… you know what… that amount of complexity *may not be enough to say the code is buggy but chances are good it can and will become buggy later on when maintenance of the code occurs*.

The above example is almost like an example pulled straight out of “Refactoring to Patterns” [Fowler]. It *can* be made more maintainable.