What is a code hotspot?

How code hotspots are measured

The standard method, from Adam Tornhill's Your Code as a Crime Scene (Pragmatic Bookshelf, 2015), has two axes:

1. Churn: how often each file changed in a recent window, from git log. See code churn.
2. Complexity: a per-file measure such as cyclomatic complexity or lines of code.

Files high on both are hotspots. A small worked example:

Only the first file is both busy and hard to change. Many teams add a third signal, prior bug fixes, because a file that keeps needing fixes is risky regardless of its complexity score.

Why code hotspots matter

Change is unevenly distributed. In most repositories a small set of files takes most of the commits, and that is where defects, merge conflicts and long reviews collect. A hotspot list turns "the code is messy" into a short, ranked list of where cleanup pays back soonest, and it keeps you from refactoring ugly code that no one touches.

How to measure code hotspots yourself

# Top 20 most-changed files in the last 90 days
git log --since="90 days ago" --no-merges --name-only --pretty=format: \
  | grep . | sort | uniq -c | sort -rn | head -20

Then score the top files for complexity. lizard (many languages) and radon cc (Python) print cyclomatic complexity per function. ESLint's complexity rule and gocyclo do the same for JavaScript and Go. Cross-tabulate the two lists by hand. If you want an interactive hotspot map and team-level analysis, CodeScene is built for that. The code hotspot analysis tools roundup compares the options.

How repowise measures code hotspots

repowise flags a file as a hotspot during git indexing when two conditions hold:

• Relative gate: its recency-weighted churn percentile is at least 0.75, the top quarter of the repository's code files. Churn weight halves every 180 days.
• Activity floors: at least 3 commits in the last 90 days, and either 8 or more commits in that window or a recency-weighted churn score of at least 0.5. The floors stop a quiet repository from calling every recently touched file a hotspot.

So the hotspot flag itself is a churn rule. Complexity enters next to it: the dashboard plots recently changed files on a churn by complexity chart, and the code health score uses complexity, so a hotspot with a low health score is the one to fix first. Non-code files are kept out of the churn ranking.

Read hotspots on the Hotspots page, in get_context (a file card carries a hotspot flag), get_risk, or with repowise risk --target <file>. Everything is computed from git and the parsed code with no model calls. See git intelligence.