Measuring Code Complexity by Its Shape and Distribution

I reckon that most engineers don't get cyclomatic complexity, or just straw man it. Case in point, the example in the piece of sorting algorithms makes no sense.

Major points implied by minimizing cyclomatic complexity: 1. Don't use conditionals if you can do without them. 2. No raw loops.

These have slowly become common advice only in the last decade.

If you generalize cyclomatic complexity so that calling functions is a single point, then another major point is that code reuse minimizes global cyclomatic complexity, and how you do it matters.

Though this case is seldom made, if ever, cyclomatic complexity actually provides a robust framework for refactoring decisions.

The sheer number of local variables can be a problem, especially when you want to refactor parts of a function to their own functions. All those variables you're using in the scope of this big function become parameters to the subfunction so you can easily end up with 6+ parameters to these refactored functions.

Yes, cyclomatic complexity might be a popular metric but it was never a good one. At least not for its original purpose. That said, I occasionally find cyclomatic complexity useful: cyclomatic complexity is a pretty good estimate on the number of unit tests a piece of code needs.