refactoring - Do you find cyclomatic complexity a useful measure?

Question

I've been playing around with measuring the cyclomatic complexity of a big code base.

Cyclomatic complexity is the number of linearly independent paths through a program's source code and there are lots of free tools for your language of choice.

The results are interesting but not surprising. That is, the parts I know to be the hairiest were in fact the most complex (with a rating of > 50). But what I am finding useful is that a concrete "badness" number is assigned to each method as something I can point to when deciding where to start refactoring.

Do you use cyclomatic complexity? What's the most complex bit of code you found?

Answer 1

We refactor mercilessly, and use Cyclomatic complexity as one of the metrics that gets code on our 'hit list'. 1-6 we don't flag for complexity (although it could get questioned for other reasons), 7-9 is questionable, and any method over 10 is assumed to be bad unless proven otherwise.

The worst we've seen was 87 from a monstrous if-else-if chain in some legacy code we had to take over.