simplifying-code

# Simplifying Code ## Principles | Principle | Rule | |-----------|------| | **Preserve behavior** | Output must do exactly what the input did — no silent feature additions or removals. Specifically preserve: async/sync boundaries, error propagation paths, and logging side effects | | **Explicit over clever** | Prefer explicit variables over nested expressions. Readable beats compact | | **Simplicity over cleanliness** | Prefer straightforward code over pattern-heavy "clean" code. Three similar lines beat a premature abstraction | | **Surgical changes** | Touch only what needs simplifying. Match existing style, naming conventions, and formatting of the surrounding code | | **Surface assumptions** | Before changing a block, identify what imports it, what it imports, and what tests cover it. Edit dependents in the same pass | ## Process 1. **Read first** — understand the full file and its dependents before changing anything 2. **Identify invariants** — what must stay the same? Public API, return types, side effects, error behavior 3. **Identify targets** — find the highest-impact simplification opportunities (see Smell → Fix table) 4. **Apply in order** — control flow → naming → duplication → data shaping → types. Structural changes first, cosmetic last 5. **Verify** — confirm no behavior change: tests pass, types check, imports resolve ## Smell → Fix | Smell | Fix | |-------|-----| | Deep nesting (>2 levels) | Guard clauses with early returns | | Long function (>30 lines...