Sloc Cloc and Code 4.0 (scc) - Finding the files that need the most attention | Ben E. C. Boyter
Sloc Cloc and Code 4.0 (scc) - Finding the files that need the most attention
2026/08/23<br>(3956 words)
So today I release the v4.0.0 version of sloc cloc and code AKA scc. While I was considering going from 3.7.0 to 3.8.0 enough new functionality landed in it that I figured a move to a new major version was worthwhile. It also was large enough to warrant another blog post going into some details, because I am genuinely excited about some of the new features in it.
I am going to go through a few of them in this post and hopefully encourage you dear reader to get the latest version and try it out.
Hotspots
I had written over 10 years ago about Google’s bug prediction which ranked files using commit history against bug fixes to determine where problematic files existed. It was interesting but discontinued because, quote:
TL;DR is that developers just didn’t find it useful. Sometimes they knew the code was a hot spot, sometimes they didn’t. But knowing that the code was a hot spot didn’t provide them with any means of effecting change for the better.
Hilariously, I forgot I wrote about this, and got multiple LLMs to find it for me, and they all linked back to that post on my blog when I asked them to find it. Apparently I am the “authoritative source” on it now.
I had always kept this in the back of my mind as something I’d like to explore more (hence trying to find it again). Recently I had a thought, since scc has a complexity estimate, can we use that to dampen out the noise? After all knowing a lot of fixes applied to a config file is not very useful, however knowing that lots of changes applied to a file with a lot of logic is. This is the same approach I took to ranking in codespelunker.
Complex files need the most attention!
As far as I can tell this is a reinvented idea from Adam Tornhill in “Your Code as a Crime Scene” (I am still reading the book after discovering this) and he even went off to create the company CodeScene as a result. Clearly there is some value in this metric.
So much for me having an original idea.
Anyway, let’s have a look at what you get, with scc running against its own codebase,
$ scc --hotspots<br>───────────────────────────────────────────────────────────────────────────────<br>Hotspots · last 1000 commits · 2019-07-21 → 2026-06-26<br>───────────────────────────────────────────────────────────────────────────────<br>File Lang Cmplx Commits Lines± Authrs Hotspot<br>───────────────────────────────────────────────────────────────────────────────<br>processor/processor.go Go 156 156 1,651 13 100.0<br>processor/workers.go Go 244 92 3,617 15 92.2<br>test-all.sh Shell 56 181 3,287 15 41.7<br>~ocessor/formatters_test.go Go 183 51 2,459 9 38.4<br>processor/workers_test.go Go 408 21 1,189 8 35.2<br>processor/formatters.go Go 44 135 5,848 17 24.4<br>main_test.go Go 261 18 995 6 19.3<br>processor/detector_test.go Go 133 32 1,175 6 17.5<br>main.go Go 40 101 1,545 17 16.6<br>processor/file.go Go 50 73 2,074 12 15.0<br>processor/detector.go Go 70 45 948 5 12.9<br>processor/file_test.go Go 75 33 826 5 10.2<br>cmd/badges/main.go Go 73 31 1,111 5 9.3<br>processor/history.go Go 173 9 941 4 6.4<br>processor/structs.go Go 25 42 247 10 4.3<br>config_test.go Go 199 4 850 3 3.3<br>~workers_regression_test.go Go 50 13 276 6 2.7<br>~rocessor/processor_test.go Go 51 12 289 4 2.5<br>~ocessor/history_authors.go Go 111 5 666 3 2.3<br>mcp.go Go 71 7 527 4 2.0<br>───────────────────────────────────────────────────────────────────────────────<br>complexity × change-frequency, normalised · 20 of 90 files shown<br>───────────────────────────────────────────────────────────────────────────────<br>As you can see the output has correctly identified that processor/processor.go and processor/workers.go are the hotspots in the codebase. I can confirm this is correct based on my own personal experience.
Why should you care? Because that summary is doing something neither complexity nor churn can do by itself.
Explain how!
In short hotspot = complexity × commit_count normalised on a scale of 0-100. We calculate the complexity for the current HEAD file, then walk backwards seeing how many times each file was changed. Note that this only counts files in HEAD. High churn files that were removed are not counted.
Lets compare it to a plain count,
$ scc --by-file -i go -s complexity<br>───────────────────────────────────────────────────────────────────────────────<br>Language Files Lines Blanks Comments Code Complexity<br>───────────────────────────────────────────────────────────────────────────────<br>Go 69 40,137 3,049 2,131 34,957 4,478<br>───────────────────────────────────────────────────────────────────────────────<br>processor/workers_test.go 2,156 374 69 1,713 408<br>main_test.go 992 80 26 886 261<br>processor/workers.go 966 146 102 718 244<br>processor/report_test.go 971 98 109 764 237<br>config_test.go 786 50 85 651 199<br>By running a simple plain count, limited to Go files...