The top finding in spf13/afero isn’t a function under active churn — it’s structural debt sitting still. The highest-ranked function, walk in path.go, carries an activity-weighted risk score of 14.06 despite zero touches in the last 30 days and 33 days since its last change; the risk here comes almost entirely from its own shape, not from anyone actively poking at it. Across 508 analyzed functions, 55 land in the critical band and 95 in high, and every single one of the top five hotspots falls into the ‘debt’ quadrant — none are in ‘fire’. That’s a specific, useful signal: I’d prioritize these by blast radius when they’re next touched, not by current commit velocity, because right now there isn’t any.
The table below ranks functions by activity-weighted risk — a score that multiplies structural complexity by recent commit frequency. A function that is both hard to understand (high cyclomatic complexity) and actively changing is a higher priority than one that is complex but untouched. CC = cyclomatic complexity (independent execution paths); ND = max nesting depth; FO = fan-out (distinct callees).
Top 5 Hotspots
| Function | File | Risk | CC | ND | FO |
|---|---|---|---|---|---|
walk | path.go | 14.1 | 27 | 4 | 7 |
readdirImpl | gcsfs/file.go | 13.7 | 27 | 3 | 13 |
newFileInfo | gcsfs/file_info.go | 13.6 | 13 | 4 | 10 |
Open | cacheOnReadFs.go | 13.3 | 28 | 3 | 7 |
Next | gcsfs/gcs_mocks.go | 13.2 | 22 | 3 | 10 |
508 functions analyzed
The quadrant split tells the real story here: zero functions in ‘fire’, 150 in ‘debt’, 3 in ‘watch’, and 355 in ‘ok’. There’s no live regression fire to put out in afero today. What there is, is a backlog of 150 structurally complex functions that nobody has touched recently, five of which are complex enough and coupled enough to land at the top of the critical band. That changes how I’d frame prioritization: this is archaeology, not triage.
Multiple return or throw paths dispersed through the body — each exit needs separate test coverage.Complex Branching×2Complex Branching
High cyclomatic complexity — many independent execution paths, each a potential bug surface and required test case.God Function×1God Function
Calls an unusually large number of distinct functions (high fan-out), making it the structural centre of gravity for a subsystem.Stale Complex×1Stale Complex
High structural complexity but untouched for a long time — structural debt that will bite whoever opens it next.
Across the top five, I count five functions flagged ‘exit_heavy’, two flagged ‘complex_branching’, one flagged ‘god_function’, and one flagged ‘stale_complex’. That’s a heavy concentration of multiple-return-path functions — every one of the top five has more than one early exit, which means each requires more test cases than a single-exit function to get real branch coverage.
walk — path.go
walk recurses through a filesystem tree, calling a caller-supplied walkFn for each entry and recursing into subdirectories. At cyclomatic complexity 27 with a nesting depth of 4, the source shows why: nested error handling for filepath.SkipDir, a directory-listing branch, and a per-entry loop that itself branches on lstatIfPossible succeeding or failing, then recurses and re-checks the error against SkipDir again on the way back up. That’s the ‘complex_branching’ and ‘exit_heavy’ tags earning their keep — I count at least five distinct return points, each with different error semantics depending on whether the failing entry was a directory. It hasn’t been changed in 33 days and has had zero touches in the last 30 days, but one of its four total commits is bug-linked, per the file’s commit history. Combined with a fan-out of 7 (it calls itself, walkFn, readDirNames, lstatIfPossible, and more), this is the kind of function where a one-line fix to the SkipDir handling could silently break directory-skip semantics elsewhere in the walk. My recommendation: extract the per-entry handling (stat, error-check, recurse) into its own helper so the SkipDir logic isn’t duplicated at two nesting levels — that alone should cut the branching by a third.
readdirImpl — gcsfs/file.go
This one is the outlier of the group, and the metrics make it obvious why: cyclomatic complexity 27, but fan-out of 13 — the highest of any function in the top five — plus a ‘god_function’ tag. It pulls in Sync, Stat, path-splitting, a GCS bucket-object iterator, newFileInfoFromAttrs, sorting, and more, all inside one method. The source shows a paging loop over a GCS object iterator with three separate continue/skip conditions (empty name, empty name-and-prefix, matching the file’s own name) plus a reset-and-return branch on iterator.Done. It hasn’t been changed in 1202 days — over three years — the longest dormancy in this list, yet the file’s commit history shows a bug-fix fraction of 0.5, meaning half of its ten recorded commits were tagged as fixes. That combination — long dormancy, high coupling, and a history that’s half bug fixes — is exactly the ‘stale_complex’ signature: nobody is actively maintaining this pagination logic, but the historical fix rate suggests it wasn’t easy to get right the first several times. If GCS-backed directory listing is still a supported path, this deserves a read-through before the next person has to modify it under time pressure.
newFileInfo — gcsfs/file_info.go
Lower complexity than the first two (cyclomatic complexity 13) but the deepest nesting in the group at 4, plus a fan-out of 10. The source shows why: it fetches object attributes, and on error checks three different cases — an empty-object-name error that means ‘this is the root,’ an ErrObjectDoesNotExist case that triggers a second GCS query to check for a virtual folder prefix, and a generic fallback error. That’s three different recovery paths nested inside a single error branch, each with its own return. It’s part of the same gcsfs package as readdirImpl, and its file-level history shows a bug-fix fraction of 0.3333 across six commits — lower than its neighbor but still non-trivial. It hasn’t been changed in 33 days. I’d flag this as a good candidate for decompose-conditional: pull the ‘does this name represent a virtual folder’ check into its own named function, since it’s currently buried inside an error-handling branch where it’s easy to miss.
Open — cacheOnReadFs.go
The highest raw cyclomatic complexity in the top five, at 28, driven by a switch over four cache states (cacheLocal, cacheMiss, cacheStale, cacheHit) where two of the branches (cacheStale, cacheHit) have their own nested directory check and only conditionally return, falling through to a shared code path at the bottom that opens both the base and layer filesystems and wraps them in a UnionFile. That fallthrough behavior is subtle — it’s easy to read the switch and assume every case returns, when in fact cacheStale and cacheHit only return early for non-directory files. This function hasn’t been changed in 2990 days — over eight years — making it the most dormant function in this entire list. Its file-level bug-fix fraction sits at 0.2857 across seven commits, and a pull-request review comment density of 0.3333 suggests reviewers have flagged parts of this file before. Nobody is actively touching it, but if the caching semantics ever need to change, this switch-with-fallthrough shape is the first place I’d expect a subtle regression. A safe first step: add an explicit return or comment at the end of each switch case stating why it falls through, so the shared bottom path isn’t a silent trap.
Next — gcsfs/gcs_mocks.go
This is a mock iterator implementation, not production filesystem logic, but it’s still worth a note because it’s the fifth-highest-scoring function in the repository. Cyclomatic complexity 22 with a fan-out of 10 comes from branching on whether the mock directory has already been opened, whether the target is a directory or a single file, and then building up a slice of storage.ObjectAttrs differently in each case before returning them one at a time. It hasn’t been changed in 423 days, and its file-level bug-fix fraction is 0.5 across eight commits. Because this is test-support code rather than a runtime path, I’d deprioritize it relative to the other four — but if the gcsfs test suite starts showing flaky iteration behavior, this is the function I’d check first, given how much branching happens before the first item is ever returned.
Patterns Found
Antipatterns detected across the top functions in this snapshot:
| Pattern | Occurrences |
|---|---|
exit_heavy | 5 |
complex_branching | 2 |
god_function | 1 |
stale_complex | 1 |
These labels belong to two tiers — Tier 1 (structural): complex_branching, deeply_nested, exit_heavy, long_function, god_function. Tier 2 (relational/temporal): hub_function, cyclic_hub, middle_man, neighbor_risk, stale_complex, churn_magnet, shotgun_target, volatile_god.
See more analyses with these patterns: complex_branching, exit_heavy, god_function, stale_complex.
Reproduce This Analysis
git clone https://github.com/spf13/afero
cd afero
git checkout 768f1fb0e5535b77d90e44c531aacd652aabd96a
hotspots analyze . --mode snapshot --explain-patterns --forceTo run the same analysis on your own codebase, run hotspots analyze . --mode snapshot in any local git repo — no configuration required.
I use Hotspots to highlight structural and activity risk — not “bad code.” I treat these findings as a prioritization aid, not a bug predictor. Editorial policy →