Evaluate Hotspots with Complexity Trends

We can find out how severe a potential problem is via a complexity trend analysis, which looks at the accumulated complexity of the file over time. The trend is calculated by fetching each historic version of a hotspot and calculating the code complexity of each historic revision.

You will soon learn more about how complexity is calculated, but let’s start with a specific example from our top hotspot. As you see in the figure, ControllerActionInvokerTest.cs has become much more complicated recently.^[21]

The trend tells the story of our hotspot. We see that it grew dramatically back in May 2016. Since then the size of the file hasn’t changed much, but the complexity continues to grow. This means the code in the hotspot gets harder and harder to understand. We also see that the growth in complexity isn’t followed by any increase in descriptive comments. So if you ever struggled to justify a refactoring … well, it doesn’t get more evident than in cases like this. All signs point to a file with maintenance problems.

We’ll soon learn to follow up on this finding and get more detailed information. Before we go there, let’s see how the complexity trend is calculated and why it works.

What Is Complexity, Anyway?

While we used lines of code as a proxy for complexity in our hotspot analysis, the same metric won’t do the trick here. We’ll get more insights if the trend is capable of differentiating between growth in pure size versus growth in complexity. This latter case is typical of code that is patched with nested conditionals; the lines of code probably grow over time, but the complexity of each line grows more rapidly. To make this distinction we need to measure a property of the code, not just count lines.

The indentation-based complexity metric provides one such approach. It’s a simple metric that has the advantage of being language neutral. The figure illustrates the general principle.

With indentation-based complexity we count the leading tabs and whitespaces to convert them into logical indentations. This is in stark contrast to traditional metrics that focus on properties of the code itself, such as conditionals and loops. This works because indentations in code carry meaning. Indentations are used to increase readability by separating code blocks from each other. We never indent code at random (and if we do, we have more fundamental problems than identifying hotspots). Therefore, the indentations of the code we write correlate well with traditional complexity metrics. (See Reading Beside the Lines: Indentation as a Proxy for Complexity Metrics. Program Comprehension, 2008. ICPC 2008. The 16th IEEE International Conference on [HGH08] for an evaluation of indentation-based complexity on 278 projects compared to traditional complexity metrics.) I did say it was simple, didn’t I?

Know the Biases in Complexity Trends

In all fairness, the simplicity of our metric comes with some trade-offs. First, the actual complexity number represents the number of logical indentations, so it makes little sense to discuss thresholds or compare complexity values across languages. It’s the trend that’s important, not the absolute values.

The use of leading whitespace makes the algorithm sensitive to mid-project changes in indentation style. If that happens you’ll see a sudden spike or drop in complexity without the code actually being changed. In that case the trend will still be meaningful, but you have to mentally ignore the sudden spike. Just remember that—like all models of complex processes—complexity trends are heuristics, not absolute truths.

Now that we know how complexity trends are calculated, let’s move on and discover detailed refactoring candidates.

Calculate Complexity Trends with Python
	The complexity trend algorithm is straightforward to implement. CodeScene adds a bit of filtering on top of it, but if you just want the raw data you can script it in no time. I’ve also open-sourced an implementation in Python as an example and inspiration for your own scripts.[22]