I came across an interesting post from Sriram Narayan on the ThoughtWorks blog about how to use Cyclomatic Complexity effectively.
Cyclomatic Complexity (CC) being the number of execution paths through a function or method. Sriram makes a case for measuring the CC per 100 lines of code (which he calls CC100). This concept of an average CC is interesting but I suggest misguided.
It’s as if I have a choice of writing code with lots of control statements (if, while, case, …, these increase CC) or I can alternatively choose to write it without so much control flow. I suggest this is much more to do with the nature of the problem I’m solving than the way I’m solving it.
The problem is that I can reduce the average CC quite easily without changing the number of branches. For example, I could do a straightforward extract a method to take a block of code with CC 7 out of a function with CC 49 and end up with 2 functions each with CC 7. The average for this block of code goes from 49 to 7!
Now I know what Sriram is after – he’s looking for a way to know if he’s actually reduced the raw complexity of the code by making smart use of inheritance and such like. In this case, he’d be better to count the number of code branches. If he can reduce these and keep the CC below some threshold, you could say that his code is less complex.
CC can only be meaningfully used as a threshold – e.g. it is possible to constuct any program out of funtions none of which have a CC greater than 10 (is there a proof for this?)
2 Comments
Tom Narayan
If there are less branches in the code, it is easier to read.
Have you heard of, Technical Leads mentioning that the methods should
be printable in one page. If the code easily readable and comprehensible,
you are less likely to miss something.Large size methods tend to
have cluster bugs in the methods.Cyclomatic Complexity (CC) quantifies,
when it is necessary to refactor the code.The CC number need not be
under 10. 30 is alright.
Smart use of inheritance is part of good practice in OO Design.
Chris Chedgey
Hi Tom, I have certainly come across the 1-screen rule – it makes good sense. It is harder to understand any text – be it a document, spreadsheet, or code – if part of it is invisible at all times. That’s why I pay extra for a hi-res 24 inch monitor!
That said, there is still good reason to monitor cyclomatic complexity. It is possible to squeeze a hell of a lot of branches into a screen full of code. As to the limit, I would tend to go lower than 30 – usually 15. One situation I would go higher is introducing the metric into a “mature” project where you just want to focus the team on the worst offenders (for now).
Fully agree on the use of smart inheritance, though that doesn’t necessarily mean more inheritance. There’s an enjoyable thread on that topic here.