Refactor Code for Readability and Maintainability

This prompt runs a focused readability-and-maintainability pass over code you paste in, with an explicit guardrail that behavior must not change. The five numbered goals — extracting duplicated logic, naming constants, self-documenting variables, flattening nesting, and adding comments only where intent is unclear — keep the model from rewriting your architecture or 'improving' things you didn't ask about. The required diff summary lets you review what changed and why before you trust it. Reach for it on working-but-messy code you've inherited or written in a hurry.

What you can expect back

Refactored code:

TAX_RATES = {"A": 1.08, "B": 1.05}

def calculate_total_with_tax(orders):
    total = 0
    for item in orders:
        rate = TAX_RATES.get(item["type"])
        if rate is not None:
            total += item["price"] * rate
    return total

Diff summary:
- Renamed calc -> calculate_total_with_tax; o -> orders, t -> total, i -> item for clarity.
- Replaced magic numbers 1.08 / 1.05 with a TAX_RATES constant, removing the if/elif duplication.
- Note: assumes item keys are 'price' not 'p' — confirm field names match your data.
- Behavior preserved: same totals for type A and B; unknown types still contribute 0.

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Paste enough surrounding context (imports, called helpers, type definitions) so the model doesn't rename or remove something another part of your codebase depends on.
• 02Tell it your language version and style guide up front (e.g. 'Python 3.11, follow PEP 8' or 'TypeScript strict mode') so the constants and naming match your conventions.
• 03Add 'do not add or remove any external dependencies' if you want to keep the refactor self-contained and reviewable.
• 04Ask it to flag any place where preserving behavior is impossible without a small risk, rather than silently changing logic — the diff summary is where that disclosure should live.
• 05Run your existing tests against the output before committing; if you have none, ask the model to also generate a few characterization tests that lock in current behavior.

Adapt it for your case