What's your/a good limit for cyclomatic complexity?

Question

Our customers have begun to impose cyclomatic complexity requirements on the software within our products, and our internal process "improvement" group has decided to make cyclomatic complexity part of our coding standards. Both the customer and our internal group have set their (recommendation for an) upper limit at 10. I've argued that if 10 is the recommendation/guideline, then developers will write code that hits 15 or 20. In my opinion, the limit should be set at 5 with the allowance for functions to exceed that when necessary (as determined by review or some other process).

So, my question is, what do other people do? What kind of complexity limits are you willing to to tolerate (high or low)? What do you strive for when you write code?

Update: I'm talking about complexity at the function level.

One of the responses says, "without sharing all the details the best you are going to get here is an arbitrary limit." I would go a step further and say that arbitrary limits is essentially what we're talking about. In the interest of furthering the conversation, though, what specifics would alter the answer? What, in general, would cause these limits to be increased or decreased?

Answer 1

If a function is more than a screenful of code, it sets off some mental alarms for me. Post Conditions after the function is done.

• It's as short as possible.
• It's as readable as possible - as in it communicates intent.

I dont worry too much about calculating complexity... too complex for me.

Answer 2

I think this is going to be relative to the type of problem you are trying to solve. Also, are you talking about cyclomatic complexity on a class or a package/namespace level? Or for the app as a whole?

I think you are definitely on the right track to set a low limit, with a justification process necessary for anything that exceeds it. But without sharing all the details the best you are going to get here is an arbitrary limit (like 42).

As far as what I do, I get it as low as I can, but no lower ;)

Answer 3

Looking at methods, 5 seems reasonable to me.

Any kind of language parsing seems to lead to higher-than-normal cyclomatic complexity in some apps that I've looked at. I'm sure there are other types of task that this would be expected from as well.

Answer 4

We use a red/yellow/green set of thresholds. Each of these thresholds has specific rules about when a reviewer is supposed to flag the change, generally based on what "color" the code was before, and what color it's moving to with the proposed changes.

However - we are working on a legacy code base. We measured existing code, then came up with reasonable thresholds that would allow us to move forward without a revolt from the developers. I believe our thresholds are around 5-8 for green/yellow and 8-10 for yellow/red.

Note that SEI defines thresholds, but they seem to be much more lenient. I agree with your guess that closer to 5-10 is sane and anything higher is a red flag.

Answer 5

In the general case a CC value of around 10 is reasonably strict. If most of your functions have a CC of under 10 then the likelihood is that its concise and non-complex code. I wouldn't be surprised to find relatively OK functions with a CC of around 15
You need to remember that long functions will likely have a higher CC even though they are quite simple to follow.

I'd tend to go for a value of between 10 and 16, anything higher then you'll need to look closely at the function as more often than not they're full of bugs and bad practices

Answer 6

I believe Steve McConnell (in Code Complete) recommends a number, but I can't recall what it was. For some reason, 5 sticks out, but I don't think that's it. If someone has a copy of Code Complete handy, perhaps they could tell you what was said there.

Answer 7

10 is our limit, but it has a nasty side-effect due to 'conditional logging'.

More on that with the question: 'How do you deal with conditional logging when trying to respect a limited cyclomatic complexity ?'

Answer 8

If you write your code with a TDD approach, you may find that the resulting code has an average of 3 or so. Using TDD, I rarely get monstrous methods with giant switch statements (which increase CC with every case: statement).

Organizationally, there are no requirements on CC for us. Personally, If I see a method with more than a 5, I try to whittle it down, if possible.