editing-clojure-files

Editing Clojure Files

Clojure code is a tree of forms, not lines of text. The unit of editing is the top-level form: ns, defn, def, (comment ...), etc. The structural editing tool clojure_edit_files understands this structure, auto-balances brackets via Parinfer, and returns post-edit diagnostics. Use clojure_edit_files whenever a structural edit is possible.

Delegation

Unless you have been specifically tasked with editing files yourself, always delegate file editing to a subagent. This protects the context window and isolates errors. Prefer the Clojure-editor subagent when available.

When delegating: Provide exact file paths, REPL-verified code with proper indentation, target line info, decision context, and explicit edit order instructions.

Code Shape for Tool Success

Structural editing tools operate on whole top-level forms — they read, transform, and rewrite the entire form in one pass. Smaller, simpler forms have higher success rates.

Thresholds

Metric	Target
Function length
Nesting depth	Under 4 levels
Cyclomatic complexity	Under 9 branches

Code smells that break structural edits

1. Large Method — Over ~25 lines. Split at responsibility boundaries; use defn- helpers so each is an independently editable top-level form.
2. Deep Nested Complexity — 3+ levels of let/when/if/cond inside each other. Use threading macros (->, ->>) to flatten transformations. Extract inner bodies into named functions.
3. Bumpy Road — Alternating simple and complex sections in one function. Each bump is a misalignment point. One responsibility per function.
4. Complex Method — Many conditional branches in one function. Keep case/cond/condp branch bodies to one-liners or calls. Prefer data-driven dispatch (defmethod, maps of keyword → handler) over deep conditional trees.
5. Code Duplication — Repeated structure across functions. Extract once; each duplicate doubles the chance of structural mismatch during edits.