filebrowser — an open-source file manager with a web interface — has 980 analyzed functions, 69 of which rank as critical. All five top hotspots land in the ‘fire’ quadrant, meaning they are structurally complex and under active commit pressure right now. The top-ranked function, search in frontend/src/api/search.ts, carries an activity risk of 15.18 with a recent commit activity of 14.47, a cyclomatic complexity of 22, and a max nesting depth of 6 — a combination that makes every new commit to this file a live regression risk rather than routine maintenance.
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 | frontend/src/api/search.ts | 15.2 | 22 | 6 | 14 |
<anonymous> | frontend/src/views/files/FileListing.vue | 14.0 | 31 | 3 | 7 |
getStaticHandlers | http/static.go | 13.8 | 5 | 4 | 22 |
getSettings | cmd/config.go | 13.1 | 34 | 2 | 13 |
<anonymous> | frontend/src/views/Login.vue | 13.1 | 18 | 6 | 9 |
Hotspot Analysis
search — frontend/src/api/search.ts
This function is the client-side entry point for filebrowser’s search API, responsible for constructing and dispatching search requests from the frontend. With a cyclomatic complexity of 22 and a max nesting depth of 6, it contains a significant number of independent execution paths and deeply nested conditionals — each path a required test case and each nesting level a readability hazard. A fan-out of 14 means it coordinates with 14 distinct callees, so a change here ripples broadly; combined with a recent commit activity of 14.47 in the ‘fire’ quadrant, this is a live regression risk that is actively accumulating complexity under commit pressure right now.
Recommendation: Before the next feature change, add characterization tests that cover each of the 22 distinct execution paths. Then extract the branching sub-concerns — likely request construction, parameter handling, and error routing — into dedicated helper functions to reduce both CC and nesting depth.
<anonymous> — frontend/src/views/files/FileListing.vue
This anonymous function inside FileListing.vue is almost certainly a component lifecycle hook or event handler responsible for orchestrating the file listing view’s behavior — one of the most central UI surfaces in filebrowser. Its cyclomatic complexity of 31 is high by any measure, indicating over 30 independent execution paths packed into a single anonymous scope, which makes it extremely difficult to reason about and nearly impossible to test exhaustively. At a recent commit activity of 13.4 in the ‘fire’ quadrant, this handler is actively changing right now, and the exit_heavy pattern flags that multiple return paths add to the test-coverage burden.
Recommendation: Refactor by extracting named handler functions for each major branch; naming the anonymous function itself will make stack traces and test coverage reports immediately more actionable. Aim to reduce CC below 15 as a first milestone.
getStaticHandlers — http/static.go
getStaticHandlers is responsible for wiring up the static file serving layer of filebrowser’s HTTP stack. Despite a low cyclomatic complexity of 5, its fan-out of 22 is the highest in this snapshot — it coordinates with 22 distinct callees, making it a structural hub through which a large portion of the HTTP layer is initialized. This is the god_function signal: not a function with complex branching, but one that “knows” about too many concerns at once and becomes a coupling point for the entire layer. With a max nesting depth of 4 and a risk score of 13.8 in the ‘fire’ quadrant, changes here ripple broadly and the function is under active development.
Recommendation: Map the 22 callees into responsibility groups — likely static asset serving, cache headers, routing setup, and error handling — and extract each group into a dedicated setup function. This reduces fan-out, makes the initialization sequence easier to test independently, and limits the blast radius of future HTTP layer changes.
getSettings — cmd/config.go
Based on its name and location in cmd/config.go, getSettings is responsible for reading and assembling configuration state from command-line inputs and/or stored config — a broad responsibility that the metrics confirm. Its cyclomatic complexity of 34 is in the high range, indicating a large number of conditional branches likely handling many individual config keys and their validation or defaulting logic. The god_function, exit_heavy, and long_function patterns all fire together here — it handles too many concerns, exits through multiple code paths, and is long enough that extraction is the clearest remediation path. With a recent commit activity of 12.51 in the ‘fire’ quadrant, this function is being actively modified while carrying that full complexity load.
Recommendation: Apply extract-method refactoring to group related configuration concerns into dedicated sub-functions (e.g., separate auth settings, storage settings, and defaults). This will reduce CC, eliminate the long-function signal, and make individual exit paths far easier to cover with tests.
<anonymous> — frontend/src/views/Login.vue
This anonymous function in Login.vue handles one of the most security-sensitive flows in the application: user authentication. With a cyclomatic complexity of 18 and a max nesting depth of 6, it contains a large number of decision paths packed into a single anonymous scope — a challenging combination for testing and for reasoning about edge cases in auth flows. The deeply_nested pattern reflects the ND of 6, where inner conditionals become hard to trace back to their outer guards. At a risk score of 13.1 in the ‘fire’ quadrant, this handler is actively changing.
Recommendation: Extract the distinct concerns — credential validation, error handling branches, redirect logic, and session setup — into named functions. Naming the function itself improves stack trace clarity. Reducing ND below 4 and CC below 10 should be the first milestone for this handler.
Patterns Found
Antipatterns detected across the top functions in this snapshot:
| Pattern | Occurrences |
|---|---|
god_function | 3 |
exit_heavy | 3 |
complex_branching | 2 |
deeply_nested | 2 |
long_function | 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.
Key Takeaways
- The
searchfunction infrontend/src/api/search.tshas a fan-out of 14 and CC of 22 — add characterization tests before any new feature work touches this file, or accept that each commit is an untested path through 22 branches. - The anonymous function in
FileListing.vuehas a cyclomatic complexity of 31 with multiple exit paths — giving it a name and breaking it into smaller handlers is the highest-leverage frontend refactoring available right now. getSettingsincmd/config.gotriggers god_function, exit_heavy, and long_function patterns simultaneously with a CC of 34 — all three signals point to the same fix: extract grouped configuration concerns into focused sub-functions before the next config feature is added.
Reproduce This Analysis
git clone https://github.com/filebrowser/filebrowser
cd filebrowser
git checkout 860c19ddf58665aafcf976f5299a907738214226
hotspots analyze . --mode snapshot --explain-patterns --force
To run the same analysis on your own codebase, run hotspots analyze . --mode snapshot in any local git repo — no configuration required.
Hotspots highlights structural and activity risk — not “bad code.” Findings are a prioritization aid, not a bug predictor. Editorial policy →