lossless-cut's renderer layer leads activity risk — 5 functions to address first

lossless-cut is a cross-platform video editing tool built on Electron and React; at 2,288 analyzed functions, 110 are in the critical risk band. The single most urgent finding is that App in src/renderer/src/App.tsx — with a cyclomatic complexity of 143 and fan-out of 394 — carries a recent commit activity of 18.6, meaning it is not merely a legacy complexity backlog item but a function absorbing active commits right now, compounding regression risk with every change. Four of the top five hotspots live in the renderer layer, and all five share the god function and long function antipatterns, pointing to a systemic concentration of logic that warrants a deliberate decomposition strategy.

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
App	src/renderer/src/App.tsx	20.0	143	6	394
useFfmpegOperations	src/renderer/src/hooks/useFfmpegOperations.ts	18.3	34	5	89
<anonymous>	src/renderer/src/App.tsx	17.3	32	5	51
useSegments	src/renderer/src/hooks/useSegments.tsx	17.3	51	3	137
startPlayback	src/renderer/src/MediaSourcePlayer.tsx	17.2	21	5	39

Hotspot Analysis

App — src/renderer/src/App.tsx

As the root React component of the application, App is almost certainly the central orchestrator for the entire renderer — wiring together state, routing, user interactions, and feature flags. A cyclomatic complexity of 143 means 143 independent execution paths, each a required test case and a potential bug surface; fan-out of 394 means it has direct coupling to nearly 400 distinct callees, so any internal change can ripple across virtually the entire codebase. With a recent commit activity of 18.6 — the highest in the repo — this function is being actively modified under extreme structural load, making it the single highest-priority regression risk in the project.

Recommendation: Before any refactoring, add characterization tests that exercise the dominant execution paths to establish a safety net; then apply extract-method refactoring to carve out cohesive sub-responsibilities (e.g., separate hooks or child components per major feature domain) to drive CC and fan-out to manageable levels.

useFfmpegOperations — src/renderer/src/hooks/useFfmpegOperations.ts

Based on its name and location in the hooks directory, useFfmpegOperations is the primary React hook encapsulating all FFmpeg command orchestration — likely covering export, transcode, cut, and merge operations. A CC of 34 indicates substantial branching across operation types or format conditions, nesting depth of 5 signals conditionally nested operation logic that is hard to reason about in isolation, and fan-out of 89 means changes here propagate coupling broadly across the renderer. Its recent commit activity of 16.93 confirms this is not a stable, settled abstraction — it is under active development, meaning each new operation or edge-case fix is being layered into an already high-complexity function.

Recommendation: Split useFfmpegOperations into smaller, operation-scoped hooks (e.g., one per major FFmpeg task category) to reduce fan-out and CC per unit; the multiple exit paths flagged by the exit-heavy pattern make it especially important to map all return conditions before splitting, to avoid losing edge-case handling.

useSegments — src/renderer/src/hooks/useSegments.tsx

As a hook managing segment state — likely covering creation, selection, trimming, merging, and validation of timeline segments — useSegments carries a CC of 51 and fan-out of 137, indicating it is another god hook: a single unit responsible for a wide surface of segment-related logic coupled to over a hundred callees. Notably its max nesting depth is only 3, suggesting the complexity is spread across many branching conditions rather than deeply nested blocks, which may make decomposition more tractable. With a recent commit activity of 15.9, it is actively absorbing changes — likely as new segment features or edge cases are added — making its broad fan-out a live blast-radius concern.

Recommendation: Audit the 137 fan-out callees to identify clusters of related functionality that can be extracted into dedicated sub-hooks (e.g., segment validation, segment mutation, segment selection), then refactor incrementally with regression tests covering the exit-heavy return paths.

Patterns Found

Antipatterns detected across the top functions in this snapshot:

Pattern	Occurrences
exit_heavy	5
god_function	5
long_function	5
complex_branching	4
deeply_nested	4

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

• App in src/renderer/src/App.tsx has a fan-out of 394 — before any refactoring, map its callee graph to understand blast radius, then prioritize extracting the highest-coupling sub-responsibilities first.
• useFfmpegOperations has a CC of 34 and a recent commit activity of 16.93: every new FFmpeg operation added to this hook increases the number of execution paths that need test coverage — consider splitting by operation type before the CC climbs further.
• All five top hotspots share the god function and exit-heavy patterns, signaling a systemic architectural issue in the renderer layer rather than isolated problem functions — a layer-wide decomposition strategy will be more effective than one-off refactors.

Reproduce This Analysis

git clone https://github.com/mifi/lossless-cut
cd lossless-cut
git checkout 260314db55d1e6a2f38fb6da39c3a569e5200241
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 →

$ brew install Stephen-Collins-tech/tap/hotspots

$ cargo install hotspots-cli

$ hotspots analyze .