Bad reasons to fail a Build #1976

September 2016

Here is a message I saw earlier, from an automated build process.

I can't remember if it was Team City or Jenkins, but that's not important; what is important is what it said. Object names changed to protect the innocent.

Build failed. The method [DoSomething] in class [SomethingDoer] in file [DoNothing.cs] has a Cylcomatic Complexity of 11. Cyclomatic Complexity must be 10 or less

Oh dear. That was at about 17:00 this afternoon, and as of the time of writing, my eye is still twitching angrily.

In the case above, 10 is an arbitrarily silly number, and not only that but a CC of 10 is horribly complex to begin with, so why not 5? or 9? or 7? 7 is a really cool number! Also cool is 1, 2 or 3, which would be, if I were prone to having stupid rules like this, my preferred upper limit.

But I'm not, so it isn't.


Don't do this kind of thing, please. Now don't get me wrong; it's good to keep Cyclomatic Complexity (and it's younger, trendier cousin Cognitive Complexity) as low as possible, and this is something I always encourage should be taken into account both in code reviews and in code metric reviews (you do generate these in your build system, and you do read them, don't you?)

But the key point here is that in all cases, it should be a person who is making a judgement call on when CC is out of order, not an automated task, because sometimes you just can't avoid it, and sometimes that's OK.

If you have great Test Coverage on a piece of code; and if you have Coverage that proves the code works, then the Complexity is something you should flag as a candidate for future refactoring, but it shouldn't be something that brings your CI process to a screeching halt.


The above "advice" also goes for test code coverage, on which more some other time.

Stephen Byrne

Read more posts by this author.