Cyclomatic complexity assessment and effectiveness

[luc0x61]

I partially read the book, and following some interests I have been moderately surprised that some common source code metrics are recalled as folklore.
I'll put aside the Halstead volume metric, about which I don't have enough experience to comment - and I take it as folklore myself, knowing that it can be adjusted with numbers... which doesn't sound very engineering.

I perceive differently the McCabe cyclomatic complexity, as it gives a practical measure of intricacies in the syntax tree. While it may be opinable the range of numbers going from very simple to very complex, it gives anyway a clear depiction of what is going to become too complex to handle.
Having maintained a few complex projects, where the intervention of many developers over many years has brought sources to unnecessary complexity, I find useful a tool that warns about potential pitfalls.
Then I'm sure anyone can tell that at first sight, with functions thousands of lines long and with indentation of blocks reaching tens of levels - unfortunately I had to maintain such code more often than I wished. We need anyway some helpful tool that warns on what's going on. Counting SLOC isn't enough, as I can implement a state machine with hundred of lines of trivial assignments, or an utterly complex algorithm in a few tens of lines.
I'm with Jack Ganssle in his Embedded Muse newsletter, when he recalls this need, mentioning the numbers in an old research from HP - I'm not a statistician, just an end consumer of what I can evaluate as "fair enough".

I understand then how the book if confronting evidencies, so it may well be there aren't many other well done researches on this. That I don't know, unfortunately.

[Derek-Jones]

The quantity of code, or code size, is predictive of a whole raft of program attributes. McCabe, Halstead, and SLOC are all measures of quantity. Is one of these metrics any better at predicting some attribute than the others? The available data sometimes shows sporadic differences, but then the data is very noisy and the attributes themselves are usually somewhat fuzzy.

The HP paper (Wayback machine worked better for me) doesn't say why they picked McCabe. In Figure 3 they might just as well have compared defects against SLOC, the result would have been the same. They also call out that the McCabe value is the same as the number of independent program paths, which is misleading because I suspect that readers will think that this is something useful, when it isn't.

Other metrics were proposed in the 1970s, when this was a hot research area (e.g., The Establishment and Use of Measures to Evaluate The Quality of Software Designs), people wrote PhD thesis, and McCabe even came up with an updated version of his complexity metric. Alternative metrics continue to be regularly proposed, and sometimes there is an associated dataset where the new metric happens to shine. But, so far, none have gained market share.

Why did McCabe become popular? I suspect its name, cyclomatic complexity, helped, plus an association with graph theory. Developers love a bit of fancy maths and the name adds mystic magic. Who wants to appear unsophisticated by saying they count lines of code; managers will understand what they are saying.

Why is McCabe still used? Nothing better has come along. This is because nobody is looking for anything better; I get strange looks when I suggest that researchers do this.

The book is confronting the fact that there is no real experimental evidence for most software engineering practices. It's mostly fashion driven opinion all the way down.

I need to do a better job of nailing McCabe to the floor. A blog post is in progress.

[luc0x61]

Derek, thank you for taking the time with a so articulated answer. I will take some time and read some of your linked articles, I'm sure they're interesting.

I had in the past some managers who asked me for the number of SLOC produced, to weigh my production. I found that awkward, and I partially still do today.
Maybe its just the way I code, and the way it has been done in the projects I've maintained in the past thirty-something years, but I've always found SLOC and complexity not necessarily connected.
To be fair, I have a memory that worst implementation issues I found were more in the tens to hundreds SLOCs than in thousands. However, I'm conscious it can be just a limit in my resources.

[Derek-Jones]

Thanks for highlighting my poor analysis of McCabe complexity.
Let me know if you spot any other issues.