Prompt Engineering Refactoring Complexity

Reduce Code Complexity — Flatten Nesting Without Losing Behavior

Deep nesting and tangled branching make code unreasonable. This prompt flattens control flow with guard clauses and collapses duplicate decisions — with every branch still routing the same way.

Overview

Complexity reduction is the refactor most likely to silently change behavior: inverting a condition to flatten nesting, collapsing two branches that look identical, deleting code that merely looks dead. This prompt uses the simplification goal's priorities — guard clauses over nesting, one decision encoded once, dead code removed only when proven unreachable — and pairs them with the goal's own warnings: "looks unused" is not "is unused" (reflection, dependency injection, serialization, external callers), and inverted conditions are a classic behavior-change risk. Validation confirms every input class still reaches the same outcome.

How to use this resource

  1. Flatten with guards

    Early returns and guard clauses replace nesting — the happy path reads top to bottom.

  2. Collapse repeated decisions

    The same condition decided in three places becomes one decision, decided once.

  3. Prove before deleting

    Dead code dies only with evidence of unreachability — lookalike-dead code gets flagged instead.

Why This Works

  • Guard clauses reduce reader working memory without touching semantics
  • The inverted-condition warning targets the exact spot simplifications go wrong
  • Outcome-preserving validation catches the branch that quietly flipped

Best for

  • Code reviews that keep saying "hard to follow"
  • Functions where every fix introduces a new edge case
  • Pre-work before adding features to tangled code

Not for

  • Measuring complexity or judging the code — that's the Code Review Prompt Generator
  • Simplifying the prompt itself — that's the Prompt Cleaner

Use cases

  • Flattening a five-level nested conditional into guard clauses
  • Collapsing branches that encode the same decision twice
  • Removing indirection that adds steps but no meaning

FAQ

How does this refactor prompt avoid silently changing behavior while flattening nesting?

It puts behavior above the goal explicitly. The TRANSFORMATION GUIDANCE warns that inverting conditions to flatten nesting is a classic behavior-change risk and requires verifying every branch still routes the same inputs to the same outcomes. BEHAVIOR PRESERVATION REQUIREMENTS add that if achieving the goal and preserving behavior conflict, behavior wins — the model stops and explains rather than compromising.

Will this delete code that only looks dead?

Only code proven unreachable is removed. Priority 3 removes dead code but not code that merely looks unused, and the guidance spells out the trap: "Looks unused" is not "is unused" — check for reflection, dependency injection, serialization, dynamic dispatch, and external callers first. Lookalike-dead code gets flagged instead of deleted, so it stays in your review, not silently gone.

What happens to a simplification the prompt judges too risky to apply?

It surfaces rather than silently skips. The OUTPUT REQUIREMENTS put any worthwhile-but-skipped transformation under a "Suggested but not applied" list, stating what information would unlock it. At the Balanced risk level, borderline-safe changes get the conservative version applied with the more aggressive option noted, so you decide the risk instead of the model.

More resources from Refactor Prompt Builder

Resources that pair well

Related tools

Workflows that use this resource

Tip: Save time by exploring related resources and tools that integrate with this resource.