Seeking clarifications about structuring code to reduce cyclomatic complexity

Question

Recently our company has started measuring the cyclomatic complexity (CC) of the functions in our code on a weekly basis, and reporting which functions have improved or worsened. So we have started paying a lot more attention to the CC of functions.

I've read that CC could be informally calculated as 1 + the number of decision points in a function (e.g. if statement, for loop, select etc), or also the number of paths through a function...

I understand that the easiest way of reducing CC is to use the Extract Method refactoring repeatedly...

There are somethings I am unsure about, e.g. what is the CC of the following code fragments?

1)

for (int i = 0; i < 3; i++)
    Console.WriteLine("Hello");

And

Console.WriteLine("Hello");
Console.WriteLine("Hello");
Console.WriteLine("Hello");

They both do the same thing, but does the first version have a higher CC because of the for statement?

2)

if (condition1)
    if (condition2)
        if (condition 3)
            Console.WriteLine("wibble");

And

if (condition1 && condition2 && condition3)
    Console.WriteLine("wibble");

Assuming the language does short-circuit evaluation, such as C#, then these two code fragments have the same effect... but is the CC of the first fragment higher because it has 3 decision points/if statements?

3)

if (condition1)
{
    Console.WriteLine("one");

    if (condition2)
        Console.WriteLine("one and two");
}

And

if (condition3)
    Console.WriteLine("fizz");

if (condition4)
    Console.WriteLine("buzz");

These two code fragments do different things, but do they have the same CC? Or does the nested if statement in the first fragment have a higher CC? i.e. nested if statements are mentally more complex to understand, but is that reflected in the CC?

Answer 1

1. Yes. Your first example has a decision point and your second does not, so the first has a higher CC.
2. Yes-maybe, your first example has multiple decision points and thus a higher CC. (See below for explanation.)
3. Yes-maybe. Obviously they have the same number of decision points, but there are different ways to calculate CC, which means ...

... if your company is measuring CC in a specific way, then you need to become familiar with that method (hopefully they are using tools to do this). There are different ways to calculate CC for different situations (case statements, Boolean operators, etc.), but you should get the same kind of information from the metric no matter what convention you use.

The bigger problem is what others have mentioned, that your company seems to be focusing more on CC than on the code behind it. In general, sure, below 5 is great, below 10 is good, below 20 is okay, 21 to 50 should be a warning sign, and above 50 should be a big warning sign, but those are guides, not absolute rules. You should probably examine the code in a procedure that has a CC above 50 to ensure it isn't just a huge heap of code, but maybe there is a specific reason why the procedure is written that way, and it's not feasible (for any number of reasons) to refactor it.

If you use tools to refactor your code to reduce CC, make sure you understand what the tools are doing, and that they're not simply shifting one problem to another place. Ultimately, you want your code to have few defects, to work properly, and to be relatively easy to maintain. If that code also has a low CC, good for it. If your code meets these criteria and has a CC above 10, maybe it's time to sit down with whatever management you can and defend your code (and perhaps get them to examine their policy).