The reason is that the conjunction in the condition is counted as separate branches in the control flow graph in one tool, while the other tool counts the entire if as one branch. The first behavior (value 4) is recommended in McCabe’s paper, but the later one is found in many tools as it is easier to implement (I have no explanation for the value 5, which seems to be too high).

Throw in new language features, such as the lambdas from C# and Java 8, and you are in for even more variations. So if you want to measure and compare complexity, stick with one of the tools and don’t copy thresholds from other sources blindly.

What do you want to measure?

Besides tools measuring different things for the same metric (which happens for other metrics as well), the main obstacle is the interpretation of the results. The simple interpretation is that the cyclomatic complexity is an upper bound for the number of test cases required to obtain branch coverage of the code. So, in the context of testing, cyclomatic complexity can be used to estimate the required effort for writing tests. In my opinion, this is a valid use-case for this metric.



Often, however, high “complexity” is directly translated to low readability and high maintenance costs. It turns out that complexity of the control flow graph of a piece of code is not necessarily what a human would perceive as complex.



For example, the following example results in a complexity value of 14, which is way beyond the threshold typically recommended for a single method.