Across 653 functions in rust-lang/mdBook, 50 land in the critical band and 127 fall into the structural-debt quadrant — complex code that simply isn’t being touched right now. The top hotspot, ‘search’ in searcher.js, has an activity-weighted risk of 18.31 built almost entirely from structure: cyclomatic complexity 29, nesting depth 7, and a fan-out of 93 distinct calls, yet it has sat untouched for 112 days, with 0 touches in the last 30 days. That’s not a live regression risk — it’s a time bomb waiting for the next contributor who needs to add a search feature or fix a reported bug. I’d treat this list as a map of where blast radius is highest whenever someone finally has to go back in.
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 |
|---|---|---|---|---|---|
search | crates/mdbook-html/front-end/searcher/searcher.js | 18.3 | 29 | 7 | 93 |
start_tag | crates/mdbook-html/src/html/tree.rs | 16.7 | 39 | 4 | 25 |
set | crates/mdbook-core/src/config.rs | 15.6 | 13 | 10 | 3 |
test_chapter | crates/mdbook-driver/src/mdbook.rs | 15.2 | 26 | 5 | 12 |
Q | crates/mdbook-html/front-end/playground_editor/ace.js | 14.8 | 17 | 8 | 11 |
Codemod / Tooling Files in Results
The ‘Q’ function in ace.js is part of the bundled Ace code editor (used for mdBook’s interactive playground) and ‘search’ plus ‘globalKeyHandler’ live in a similarly bundled searcher.js — all three are checked-in, minified or near-minified third-party front-end assets rather than code the mdBook team writes and reviews line by line. Their high complexity scores reflect minification and vendor design choices, not maintainability debt introduced by mdBook contributors. To exclude these from future scans, add a pattern like { "exclude": ["crates/mdbook-html/front-end/playground_editor/", "crates/mdbook-html/front-end/searcher/"] } to .hotspotsrc.json.
search — searcher.js
This is the largest self-contained IIFE driving mdBook’s client-side search: it wires up DOM references (search wrapper, searchbar, results panel), sets up a String.prototype polyfill for IE 11 compatibility, configures elasticlunr search options, and defines a cluster of nested helper functions (‘hasFocus’, ‘removeChildren’, ‘parseURL’) before getting to the actual query logic. A cyclomatic complexity of 29 combined with a nesting depth of 7 means there are many independent paths through this function, buried several levels deep — the kind of code where a one-line fix can silently break an unrelated branch. The fan-out of 93 is the number that should worry a reviewer most: this function reaches into dozens of collaborators (DOM APIs, elasticlunr, Mark.js, its own internal helpers), so any change here carries a wide blast radius even though nothing has forced that change yet. With 0 touches in the last 30 days and 112 days since the last commit, this is squarely structural debt, not active churn — the file has 6 commits on record, roughly two-thirds of which were bug fixes, suggesting this area has needed correction before, even if none are linked directly to this function. My recommendation: before anyone extends search behavior again, split the DOM-wiring, polyfill setup, and query-execution paths into separate functions so a future change only has to reason about one slice of this god function at a time.
start_tag — tree.rs
This is the one function in the top five that’s a genuinely live regression risk rather than dormant debt. start_tag sits in the ‘fire’ quadrant with 4 touches in the last 30 days and 0 days since its last change — it’s being actively worked on right now, and it carries the highest cyclomatic complexity of any hotspot in this analysis at 39. The excerpt shows a large match expression over markdown ‘Tag’ variants (Paragraph, Heading, BlockQuote, CodeBlock, HtmlBlock, and more), each arm building up a different HTML element with its own attribute logic — a large switch structure where every new tag type is another branch to keep in sync with the others. The nesting depth of 4 is moderate, but with fan-out at 25 distinct calls, changes to how one tag type is rendered risk unintended ripple effects on siblings in the same match arm. The file has 24 commits on record and averages 9 review comments per pull request, telling me reviewers are already spending real effort scrutinizing changes here — a signal this code deserves that scrutiny, not a green light to skip it. Given it’s being modified today, I’d prioritize extracting each ‘Tag’ variant’s rendering logic into its own named function before the next round of edits lands, so the match expression becomes a dispatch table rather than a 39-path decision tree.
set — config.rs
The standout number here is nesting depth: 10, the deepest of any hotspot in this analysis, on a function with only moderate cyclomatic complexity (13) and low fan-out (3). Looking at the excerpt, this is a chain of ‘if index == X’ / ‘else if let Some(key) = index.strip_prefix(…)’ branches used to route a dotted config key (‘output.html.playground’) to the right nested config struct. Each additional prefix this function needs to support (book., build., rust., output., preprocessor.) adds another link to that chain, and the nesting depth suggests some of that logic is doing more than flat dispatch. This is Rust’s config layer — the kind of code where a missed branch silently drops a user-supplied setting instead of erroring, and because it acts like a small internal schema router, bugs here tend to be quiet rather than loud. It hasn’t been touched in 289 days and shows 0 touches in the last 30, so this is pure structural debt: nobody is actively fighting this code, but whoever next adds a new top-level config section will need to extend an already 10-deep nesting chain. I’d flatten this into a match on a parsed key-prefix enum rather than sequential string comparisons — it collapses the nesting without changing behavior and makes adding a new section a one-line addition instead of another branch.
test_chapter — mdbook.rs
This function drives rustdoc --test execution across a book’s chapters, and it’s tagged with the ‘stale_complex’ pattern — the only hotspot in this set flagged that way. That pattern exists precisely because this combination (cyclomatic complexity 26, 266 days since last change, 0 touches in 30 days) means the complexity was baked in a long time ago and nobody has revisited it since. The excerpt shows a for-loop over ‘book.iter()’ with early ‘continue’ statements for chapters that don’t match a filter, plus a nested match over Rust edition variants (2015/2018/2021/2024, with a ‘panic!’ fallback) used to build up command-line arguments for a spawned ‘rustdoc’ subprocess. That’s real branching complexity: filtering logic, edition dispatch, and subprocess argument construction all living in one function with a fan-out of 12. Across 7 total commits on the file, more than half were bug fixes, suggesting this area of the test-runner has already needed correction more than once. Because nothing is actively touching it, the risk here is entirely about the next contributor who has to add a new Rust edition or change how chapter filtering works — I’d extract the edition-to-args mapping into its own small function first, since it’s the most self-contained piece and the easiest place to start peeling this apart.
Q — ace.js
This is a minified module-loader shim from the bundled Ace editor, used to power mdBook’s interactive code-playground feature. Its nesting depth of 8 is the second-highest in this analysis, but that depth is largely an artifact of aggressive minification rather than genuinely tangled application logic — variable names are single letters and the module-definition/require machinery is condensed into a handful of nested closures. It has 352 days since its last change and 0 touches in 30 days, the longest dormancy of any hotspot here, with only 1 total commit on record, which was itself a bug fix. Practically speaking, this is vendored third-party code bundled directly into the front-end tree rather than first-party logic the mdBook team is maintaining line by line, so I’m flagging it here for completeness but not recommending a refactor — see the vendor note below for how to keep files like this out of future scans.
Patterns Found
Antipatterns detected across the top functions in this snapshot:
| Pattern | Occurrences |
|---|---|
complex_branching | 6 |
god_function | 6 |
deeply_nested | 5 |
exit_heavy | 4 |
long_function | 4 |
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, deeply_nested, exit_heavy, god_function, long_function, stale_complex.
Reproduce This Analysis
git clone https://github.com/rust-lang/mdBook
cd mdBook
git checkout a57975d499a660fd11da05a9010e93fe245525ba
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 →