Hotspot Metrics

You’ve already learned about Hotspots in Hotspots. In this part of the guide you’ll learn more about the metrics behind the hotspot criteria and the rare instances of when you want to specify an alternative algorithm for hotspots.

Understand the possible Bias in Commit Styles

By default, CodeScene uses the commit frequency of each file as the Hotspot criteria; The more changes you’ve done to a file, the higher its change frequency. This default criteria is supported by several findings from academic research; change alone is the single most important metric when it comes to quality issues in code.

However, there are some rare cases when this metric becomes biased. One reason is large individual differences in commit style. Another possible source of bias is for semi-automated code updates like refactoring via a tool. If you rename a type, all other code that references that type get updated as well. This may even include hyper linked code comments. Since it’s a minor change in terms of both programmer effort and risk, one could argue that such changes are less important.

It’s important to point out that even when you experience any of the situations above you may still be fine. In a large system, such differences tend to even out. However, if you suspect that the impact is large enough to bias your data, please consider using Relative Code Churn as Hotspot criteria instead of the number of commits. Let’s see how you can configure that alternative.

Enable Relative Code Churn

Relative Code Churn is an alternative hotspot metric that calculates the amount of change in each file in terms of Lines of Code. It’s a relative metric since the churn is weighted against the total size of the code in each file.

You enable Relative Code Churn in your Project Configuration:

Relative code churn setting

Fig. 93 You can switch to “Relative Code Churn” in the project configuration.

From now on, all Hotspots are calculated based on the amount of change to their lines of code.

The Pros and Cons of Relative Code Churn

The major drawback of using churn measures to predict Hotspots, is that small files that change often get a very high churn rate. CodeScene automatically adjust for this scenario, but it’s still something you want to be aware of.

Relative Code Churn has other uses besides providing an attractive alternative in case of biased commit styles. For example, you’ll find that old, now stable files fall much faster on the Hotspot ranking ones the development efforts shift to other parts of the codebase. With number of commits, a historic Hotspot that have since been refactored, may still stick around the top ranking due to its troubled past.

Finally, you’ll probably find that there’s a high correlation between the two Hotspot metrics. In that case, prefer the number of commits metric since it’s easier to reason about.