# File Size Refactoring Plan for Principal-Level Review
## Executive Summary
**Current Status:** Multiple files exceed 300 lines, violating Principal-level code quality standards.
**Target:** All files ≤ 200 lines (exceptions: type definitions up to 250 lines)
**Priority:** HIGH - Principal Engineers will flag large files as maintainability issues
---
## Files Requiring Refactoring
### 🔴 CRITICAL (>600 lines) - Must Split Immediately
#### 1. `src/commands/git.rs` - **1,206 lines**
**Issue:** Contains all Git command implementations in one file
**Refactoring Strategy:**
- Split into multiple command modules:
- `commands/git/stage.rs` - Stage/unstage commands
- `commands/git/commit.rs` - Commit commands
- `commands/git/branch.rs` - Branch operations
- `commands/git/merge.rs` - Merge/rebase operations
- `commands/git/reset.rs` - Reset operations
- `commands/git/patch.rs` - Patch operations
- `commands/git/remote.rs` - Remote operations
- `commands/git/utils.rs` - Shared utilities
**Estimated Reduction:** 1,206 → ~150 lines per file (8 files)
#### 2. `src/app/reducers/status_reducer.rs` - **790 lines**
**Issue:** All status-related reducer logic in one file
**Refactoring Strategy:**
- Split by functionality:
- `reducers/status/navigation.rs` - Navigation actions (Up, Down, PageUp, etc.)
- `reducers/status/selection.rs` - Selection actions (NextStaged, NextConflict, etc.)
- `reducers/status/filtering.rs` - Filtering actions
- `reducers/status/rebase_todo.rs` - Rebase todo actions
- `reducers/status/mod.rs` - Main reducer that delegates
**Estimated Reduction:** 790 → ~150 lines per file (5 files)
#### 3. `src/palette/registry.rs` - **766 lines**
**Issue:** All command definitions in one registry
**Refactoring Strategy:**
- Split by category:
- `palette/registry/git_operations.rs` - Git operation commands
- `palette/registry/navigation.rs` - Navigation commands
- `palette/registry/ui.rs` - UI commands
- `palette/registry/workflow.rs` - Workflow commands
- `palette/registry/mod.rs` - Registry that combines all
**Estimated Reduction:** 766 → ~150 lines per file (5 files)
---
### 🟡 HIGH PRIORITY (400-600 lines) - Should Split
#### 4. `src/git/cli.rs` - **621 lines**
**Issue:** All Git CLI operations in one file
**Refactoring Strategy:**
- Split by operation type:
- `git/cli/status.rs` - Status operations
- `git/cli/diff.rs` - Diff operations
- `git/cli/branch.rs` - Branch operations
- `git/cli/remote.rs` - Remote operations
- `git/cli/mod.rs` - Main CLI wrapper
**Estimated Reduction:** 621 → ~120 lines per file (5 files)
#### 5. `src/palette/render.rs` - **601 lines**
**Issue:** All palette rendering logic in one file
**Refactoring Strategy:**
- Split by rendering concern:
- `palette/render/list.rs` - Command list rendering
- `palette/render/preview.rs` - Preview rendering
- `palette/render/layout.rs` - Layout calculation
- `palette/render/highlight.rs` - Match highlighting
- `palette/render/mod.rs` - Main renderer
**Estimated Reduction:** 601 → ~120 lines per file (5 files)
#### 6. `src/config/theme.rs` - **585 lines**
**Issue:** All theme configuration in one file
**Refactoring Strategy:**
- Split by theme component:
- `config/theme/colors.rs` - Color definitions
- `config/theme/styles.rs` - Style definitions
- `config/theme/loader.rs` - Theme loading
- `config/theme/mod.rs` - Main theme module
**Estimated Reduction:** 585 → ~150 lines per file (4 files)
#### 7. `src/components/manager/renderers.rs` - **552 lines**
**Issue:** All popup/modal rendering in one file
**Refactoring Strategy:**
- Split by UI component:
- `components/manager/renderers/feedback.rs` - Feedback messages
- `components/manager/renderers/popups.rs` - Popups (conflicts, rebase, etc.)
- `components/manager/renderers/inputs.rs` - Input modals (commit, branch, stash)
- `components/manager/renderers/mod.rs` - Main renderer
**Estimated Reduction:** 552 → ~140 lines per file (4 files)
---
### 🟢 MEDIUM PRIORITY (300-400 lines) - Consider Splitting
#### 8. `src/app/actions.rs` - **544 lines**
**Status:** ⚠️ **ACCEPTABLE** - Large enum definition
**Rationale:** Action enum naturally grows with features. This is acceptable for type definitions.
**Action:** Add better organization with comments grouping related actions
#### 9. `src/app/state.rs` - **466 lines**
**Status:** ⚠️ **ACCEPTABLE** - Large struct definition
**Rationale:** AppState is the central state struct. Splitting would reduce clarity.
**Action:** Add better organization with comments grouping related fields
#### 10. `src/components/manager/event_handlers.rs` - **462 lines**
**Issue:** All event handlers in one file
**Refactoring Strategy:**
- Split by handler type:
- `components/manager/handlers/modal.rs` - Modal handlers (commit, branch, stash)
- `components/manager/handlers/popup.rs` - Popup handlers (conflicts, rebase)
- `components/manager/handlers/global.rs` - Global key handlers
- `components/manager/handlers/mod.rs` - Main handler dispatcher
**Estimated Reduction:** 462 → ~120 lines per file (4 files)
#### 11. `src/components/manager/mod.rs` - **444 lines**
**Status:** ⚠️ **BORDERLINE** - Component manager coordination
**Action:** Extract helper functions to reduce size
#### 12. `src/app/application.rs` - **404 lines**
**Status:** ⚠️ **BORDERLINE** - Application coordination
**Action:** Already improved with helper functions, consider extracting more
---
## Refactoring Priority
### Phase 1: Critical (Immediate)
1. ✅ `commands/git.rs` (1,206 lines) - Split into 8 modules
2. ✅ `app/reducers/status_reducer.rs` (790 lines) - Split into 5 modules
3. ✅ `palette/registry.rs` (766 lines) - Split into 5 modules
### Phase 2: High Priority (Next)
4. `git/cli.rs` (621 lines) - Split into 5 modules
5. `palette/render.rs` (601 lines) - Split into 5 modules
6. `config/theme.rs` (585 lines) - Split into 4 modules
7. `components/manager/renderers.rs` (552 lines) - Split into 4 modules
### Phase 3: Medium Priority (Polish)
8. `components/manager/event_handlers.rs` (462 lines) - Split into 4 modules
9. `components/manager/mod.rs` (444 lines) - Extract helpers
10. `app/application.rs` (404 lines) - Already improved, minor cleanup
---
## Refactoring Principles
### 1. **Single Responsibility**
Each file should have one clear purpose
### 2. **Logical Grouping**
Group related functionality together
### 3. **Maintain Clear Interfaces**
Use `mod.rs` to maintain public API
### 4. **Preserve Functionality**
No behavior changes, only organization
### 5. **Documentation**
Add module-level documentation explaining organization
---
## Expected Outcomes
### Before Refactoring
- 5 files > 600 lines
- 7 files > 400 lines
- 12 files > 300 lines
### After Refactoring
- 0 files > 300 lines
- All files ≤ 200 lines (except type definitions)
- Better code organization
- Easier to navigate and maintain
- Principal-level compliance
---
## Implementation Notes
### Module Structure Example
```rust
// commands/git/mod.rs
pub mod stage;
pub mod commit;
pub mod branch;
// ... re-export public types
pub use stage::StageFilesCommand;
```
### Benefits
- **Easier Navigation:** Find code faster
- **Better Testing:** Test modules independently
- **Reduced Cognitive Load:** Smaller files are easier to understand
- **Parallel Development:** Multiple engineers can work on different modules
- **Principal-Level Compliance:** Meets Google code quality standards
---
## Recommendation
**For Principal Engineer Review:** Complete Phase 1 (Critical) before submission.
**Rationale:**
- Files over 600 lines are immediate red flags
- Principal Engineers will question maintainability
- Refactoring demonstrates code quality awareness
- Shows ability to organize large codebases
**Time Estimate:**
- Phase 1: 2-3 hours
- Phase 2: 3-4 hours
- Phase 3: 1-2 hours
**Total:** 6-9 hours for complete refactoring