Code Quality and Complexity Analysis Report

Project: wifi-densepose (ruview) Date: 2026-04-05 Analyzer: QE Code Complexity Analyzer v3 Scope: Full codebase -- Rust, Python, C firmware, TypeScript/React Native

Executive Summary

This report analyzes code complexity across the entire wifi-densepose project -- 153,139 lines of Rust, 21,399 lines of Python, 7,987 lines of C firmware, and 7,457 lines of TypeScript/React Native. The analysis identified 231 Rust functions with cyclomatic complexity > 10, a single 4,846-line Rust file that constitutes the most critical hotspot in the entire codebase, and systematic code duplication patterns that inflate maintenance cost.

Key Findings

Overall Quality Score: 62/100 (MODERATE)

The Python and TypeScript codebases are well-structured. The Rust codebase has pockets of extreme complexity concentrated in the sensing server, and the C firmware has proportionally the highest rate of complex functions.

1. Rust Codebase (153,139 lines, 17 crates)

1.1 Crate Size Breakdown

1.2 Top 20 Most Complex Rust Functions

1.3 Critical Hotspot: sensing-server/src/main.rs (4,846 lines)

This is the single worst file in the entire codebase. At 4,846 lines, it is 9.7x the project's 500-line guideline and contains:

God Object: AppStateInner (lines 424-525)

• 40+ fields spanning unrelated concerns: vital signs, recording state, training state, adaptive model, per-node state, field model calibration, model management
• Violates Single Responsibility Principle -- mixes signal processing state, application lifecycle, network I/O, and persistence concerns

Monolithic main() function (lines 4070-4846)

• CC=121, 776 lines, nesting depth 8
• Handles CLI dispatch (benchmark, export, pretrain, embed, build-index, train, server startup) all in one function
• Should be decomposed into at least 8 separate command handlers

udp_receiver_task() function (lines 3504-3926)

• CC=66, 422 lines, nesting depth 8
• Handles three different packet types (vitals 0xC511_0002, WASM 0xC511_0004, CSI 0xC511_0001) in a single monolithic match chain
• Each branch duplicates the full sensing update construction and broadcast logic

Systematic Code Duplication (6 instances):

• smooth_and_classify / smooth_and_classify_node -- identical logic, differs only in operating on AppStateInner vs NodeState (could use a trait)
• smooth_vitals / smooth_vitals_node -- same pattern, identical algorithm duplicated for AppStateInner vs NodeState
• SensingUpdate construction -- built identically in 6 different places (WiFi task, WiFi fallback, simulate task, ESP32 CSI handler, ESP32 vitals handler, broadcast tick)
• Person count estimation -- repeated in WiFi, ESP32, and simulate paths

1.4 Code Smell: wasm-edge Vendor Modules

The wifi-densepose-wasm-edge crate contains 68 files (28,888 lines), with nearly every module implementing a process_frame function following the same pattern. At least 20 of these have CC > 25. This is a textbook case for:

• Extracting a common process_frame trait with shared scaffolding
• Using a generic signal pipeline builder

1.5 Oversized Rust Files (> 500 lines, violating project guideline)

92 Rust files exceed the 500-line guideline. The worst offenders:

1.6 Dependency Analysis

No circular dependencies detected. The dependency graph is clean and follows the documented crate publishing order. Maximum depth is 3 (CLI -> MAT -> core/signal/nn).

2. Python Codebase (21,399 lines, 63 files)

2.1 Overall Assessment: GOOD

The Python codebase is significantly better structured than the Rust codebase. Only 16 functions (1.8%) exceed CC=10, and no function exceeds CC=20. The code follows clean separation of concerns with distinct layers (api, services, core, hardware, middleware, sensing).

2.2 Top 10 Most Complex Python Functions

2.3 Files Exceeding 500 Lines

2.4 Observations

• Well-typed: Uses type hints consistently throughout
• Clean separation: API routers, services, core, and middleware are distinct
• Moderate nesting: Only 7 functions (0.8%) exceed nesting depth 4
• Minor concern: _print_text_status (CC=18, 126 lines) in commands/status.py is essentially a large formatting function that could be split into per-component formatters

3. C Firmware (7,987 lines, 32 files)

3.1 Overall Assessment: MODERATE

The C firmware has the highest proportion of complex functions (15.2% with CC>10). This is partly expected for embedded C, but several functions warrant attention.

3.2 Top 10 Most Complex C Functions

3.3 Critical Hotspot: nvs_config_load (CC=59, 314 lines)

This function in nvs_config.c has the highest complexity of any C function. It loads 30+ configuration parameters from NVS flash storage, each with its own error handling and default-value fallback. This is a classic case for:

• Table-driven configuration loading with a descriptor array
• Macro-based parameter definition to eliminate repetition

3.4 edge_processing.c (1,067 lines)

This is the only C file exceeding 1,000 lines. It implements the full dual-core CSI processing pipeline (11 processing stages). The process_frame function (CC=40, 185 lines) combines phase extraction, variance tracking, subcarrier selection, bandpass filtering, BPM estimation, presence detection, and fall detection in a single function.

3.5 Stack Safety Concern

The code documents that process_frame + update_multi_person_vitals combined used 6.5-7.5 KB of the 8 KB task stack, necessitating static scratch buffers. This indicates the functions are pushing resource limits and should be decomposed for safety margin.

4. TypeScript/React Native (7,457 lines, 71 files)

4.1 Overall Assessment: GOOD

The UI codebase is the cleanest in the project. Only 3 functions exceed CC=10, no file exceeds 1,000 lines, and the component architecture follows React best practices with proper separation of screens, components, stores, and services.

4.2 Critical Hotspot: GaussianSplatWebView.web.tsx (CC=70, 747 lines)

This is the only significant complexity hotspot in the TypeScript codebase. The GaussianSplatWebViewWeb component (CC=70, 467 lines) manages:

• Three.js scene initialization and teardown
• Multi-person skeleton rendering with DensePose-style body parts
• Signal field visualization
• Animation loop management
• Frame data parsing and keypoint mapping

This component should be decomposed into:

• A Three.js scene manager (initialization, camera, lighting, animation)
• A skeleton renderer (body parts, keypoints, bones)
• A signal field renderer (grid, heatmap)
• A data adapter (frame parsing, person mapping)

4.3 Well-Structured Patterns

• Zustand stores (poseStore.ts, matStore.ts, settingsStore.ts): Clean state management with proper typing
• Custom hooks (useMatBridge, useOccupancyGrid, useGaussianBridge): Good separation of WebSocket logic from UI components
• Component decomposition: Screens are split into sub-components (AlertCard, SurvivorCounter, MetricCard, etc.)

5. Top 20 Hotspots (Cross-Codebase, Risk-Ranked)

Hotspots are ranked by a composite score combining complexity, file size, nesting depth, and duplication density.

6. Code Smell Catalog

6.1 God Class / God File

6.2 Duplicated Code

Estimated duplicated code in main.rs alone: ~450 lines (9.3% of file).

6.3 Deep Nesting (> 4 levels)

215 Rust functions exceed 4 levels of nesting. The worst cases:

• main(): 8 levels (lines 4070-4846)
• udp_receiver_task(): 8 levels (lines 3504-3926)
• Multiple process_frame in wasm-edge: 7-8 levels

6.4 Long Parameter Lists (> 5 parameters)

43 Rust functions have more than 5 parameters. Notable:

• process_frame variants in wasm-edge: 5-7 parameters each
• extract_features_from_frame: 3 parameters but returns a 5-tuple

6.5 Repetitive Vendor Modules (wasm-edge)

The wifi-densepose-wasm-edge crate has 68 files following a near-identical pattern. At least 35 have a process_frame function with CC > 20. A trait-based or macro-based approach would reduce this to a fraction of the code.

7. Testability Assessment

8. Refactoring Recommendations

Priority 1: CRITICAL -- sensing-server/main.rs Decomposition

Estimated effort: 3-5 days Impact: Reduces maintenance cost for the most-changed file in the project

1. Extract AppStateInner into bounded contexts:

   • SensingState -- frame history, features, classification
   • VitalSignState -- HR/BR smoothing, detector, buffers
   • RecordingState -- recording lifecycle, file handles
   • TrainingState -- training status, config
   • ModelState -- loaded model, progressive loader, SONA profiles
   • NodeRegistry -- per-node states, pose tracker, multistatic fuser

2. Extract command handlers from main():

   • run_benchmark() (lines 4082-4089)
   • run_export_rvf() (lines 4092-4142)
   • run_pretrain() (lines 4145-4247)
   • run_embed() (lines 4250-4312)
   • run_build_index() (lines 4315-4357)
   • run_train() (lines 4360-end)
   • run_server() -- the remaining server startup

3. Extract SensingUpdate builder: Create a SensingUpdateBuilder that encapsulates the repeated 6-instance construction pattern.

4. Unify node vs global variants via trait:

   rustCopy

   trait SmoothingState {
       fn smoothed_motion(&self) -> f64;
       fn set_smoothed_motion(&mut self, v: f64);
       // ... etc
   }
   impl SmoothingState for AppStateInner { ... }
   impl SmoothingState for NodeState { ... }
   

   Then a single smooth_and_classify<S: SmoothingState>() replaces both copies.

5. Extract udp_receiver_task into packet-type handlers:

   • handle_vitals_packet()
   • handle_wasm_packet()
   • handle_csi_frame()

Priority 2: HIGH -- C Firmware nvs_config_load Table-Driven Refactor

Estimated effort: 1 day Impact: Reduces CC from 59 to approximately 5

Replace the 314-line sequential NVS load with a descriptor table:

typedef struct {
    const char *key;
    nvs_type_t type;
    void *dest;
    size_t size;
    const void *default_val;
} nvs_param_desc_t;

static const nvs_param_desc_t params[] = {
    {"node_id", NVS_U8, &cfg->node_id, 1, &(uint8_t){1}},
    // ... 30+ entries
};

Priority 3: HIGH -- wasm-edge process_frame Trait Extraction

Estimated effort: 2-3 days Impact: Reduces 28,888 lines by an estimated 30-40%

Define a common trait:

trait WasmEdgeModule {
    fn name(&self) -> &str;
    fn init(&mut self, config: &ModuleConfig);
    fn process_frame(&mut self, ctx: &mut FrameContext) -> Vec<WasmEvent>;
}

Extract shared signal processing (phase extraction, variance tracking, BPM estimation) into reusable pipeline stages.

Priority 4: MEDIUM -- GaussianSplatWebView.web.tsx Decomposition

Estimated effort: 1 day Impact: Reduces CC from 70 to approximately 10-15 per component

Split into:

• SceneManager -- Three.js initialization, camera, lighting
• SkeletonRenderer -- body parts, keypoints, bones
• SignalFieldRenderer -- grid, heatmap visualization
• useFrameAdapter -- data parsing hook

Priority 5: MEDIUM -- edge_processing.c Pipeline Decomposition

Estimated effort: 1-2 days Impact: Reduces process_frame CC from 40 to ~10; improves stack safety

Split into stage functions:

static void stage_phase_extract(frame_ctx_t *ctx);
static void stage_variance_update(frame_ctx_t *ctx);
static void stage_subcarrier_select(frame_ctx_t *ctx);
static void stage_bandpass_filter(frame_ctx_t *ctx);
static void stage_bpm_estimate(frame_ctx_t *ctx);
static void stage_presence_detect(frame_ctx_t *ctx);
static void stage_fall_detect(frame_ctx_t *ctx);

Priority 6: LOW -- Python Status Formatter Decomposition

Estimated effort: 0.5 days Impact: Reduces _print_text_status CC from 18 to ~5 per formatter

Split _print_text_status (126 lines) into per-component formatters: _format_api_status, _format_hardware_status, _format_streaming_status, etc.

9. Quality Gate Recommendations

Proposed Complexity Thresholds for CI/CD

Recommended Immediate Actions

1. Block new functions with CC > 25 in CI (addresses future growth)
2. Block new files exceeding 500 lines (enforces project guideline)
3. Add complexity linting via cargo clippy with custom lints or complexity-rs
4. Prioritize the sensing-server decomposition -- it is the single largest contributor to technical debt in the project

10. Complexity Distribution Charts (Text)

Rust Cyclomatic Complexity Distribution

CC Range    | Functions | Percentage | Bar
------------|-----------|------------|----------------------------------
  1-5       |     5,728 |     86.2%  | ####################################
  6-10      |       682 |     10.3%  | ####
 11-15      |       107 |      1.6%  | #
 16-20      |        50 |      0.8%  | 
 21-30      |        41 |      0.6%  | 
 31-50      |        24 |      0.4%  | 
   >50      |         9 |      0.1%  | 

Python Cyclomatic Complexity Distribution

CC Range    | Functions | Percentage | Bar
------------|-----------|------------|----------------------------------
  1-5       |       740 |     83.3%  | ####################################
  6-10      |       132 |     14.9%  | ######
 11-15      |        13 |      1.5%  | #
 16-20      |         3 |      0.3%  | 

C Firmware Cyclomatic Complexity Distribution

CC Range    | Functions | Percentage | Bar
------------|-----------|------------|----------------------------------
  1-5       |        73 |     50.3%  | ####################################
  6-10      |        50 |     34.5%  | #########################
 11-15      |         6 |      4.1%  | ###
 16-20      |         8 |      5.5%  | ####
 21-30      |         3 |      2.1%  | ##
   >30      |         5 |      3.4%  | ##

Appendix A: Methodology

Metrics Calculated

• Cyclomatic Complexity (CC): McCabe's cyclomatic complexity counting decision points (if, else if, match, for, while, boolean operators, match arms)
• Cognitive Complexity: Approximated via nesting depth and CC combination
• Function Length: Raw line count from function signature to closing brace
• Nesting Depth: Maximum brace/indent depth within function body
• Parameter Count: Number of non-self parameters
• File Size: Total lines including comments and blank lines

Tools Used

• Custom Python AST analysis for Python files
• Custom regex-based analysis for Rust, C, and TypeScript files
• AST parsing provides higher accuracy for Python; regex-based analysis may slightly overcount CC for Rust (e.g., match arms in comments) but provides consistent cross-language comparison

Limitations

• CC for Rust match arms counted via => may include non-decision match arms
• TypeScript analysis captures top-level and exported functions but may miss deeply nested callbacks
• C analysis requires function signatures to start at column 0
• Dead code detection is heuristic-only (unused imports not checked at scale)

Report generated by QE Code Complexity Analyzer v3 Codebase snapshot: commit 85434229 on branch qe-reports