Refactor code for readability without changing behavior

You are a senior [LANGUAGE] engineer. Refactor the code below for readability and maintainability.

Context:
- What the code does: [PURPOSE]
- Language and framework version: [e.g. "Python 3.12, Django 5"]
- Style guide or linter: [e.g. "PEP 8, ruff defaults"]
- Parts that must not change: [e.g. "public function signatures", "log messages parsed by monitoring"]

Hard rule: the external behavior must stay identical. Same inputs, same outputs, same side effects, same exceptions. Do not fix bugs silently; if you find one, list it separately.

Work in this order:
1. Summarize what the code does in 3-5 bullet points so I can confirm you understood it.
2. List the readability problems you see (naming, long functions, deep nesting, duplication, magic numbers, unclear control flow).
3. Propose a sequence of small refactoring steps, each one safe on its own (e.g. "extract function", "rename variable", "replace nested ifs with early returns").
4. Show the final refactored code.
5. List any behavior that could change by accident (ordering, floating point, mutability, error types) and the tests I should run or add to confirm nothing changed.
6. Under "Possible bugs found", list issues you noticed but did not fix.

Code:
```
[PASTE CODE]
```

Example (excerpt):
Steps:
1. Rename `d` to `orders_by_customer` (no behavior change).
2. Extract the discount calculation (lines 18-34) into `calculate_discount(order)`.
3. Replace the three nested ifs in `process()` with early returns.

Risk: the original loop mutates `items` while iterating; the new version copies the list first. Add a test with duplicate items to confirm the totals match.

Possible bugs found: `total` is never reset between customers (line 41).

When to use it

Use this prompt when a file has grown hard to read, before adding a feature to messy code, or when you inherit a function that nobody wants to touch. It is meant for refactoring in the strict sense: changing the structure of the code without changing what it does. That makes it safer than a generic “clean up this code” request, which often mixes style changes with unrequested behavior changes.

How to customize it

• [LANGUAGE] and the framework version keep suggestions idiomatic and avoid features your runtime does not support.
• [PURPOSE] lets the model choose names that describe the domain instead of generic names like data or result.
• [STYLE GUIDE] aligns the output with your linter so the diff is not full of formatting noise.
• [PARTS THAT MUST NOT CHANGE] protects public interfaces, database queries or log formats that other systems depend on.
• [PASTE CODE] works best with one module or a few related functions at a time.

Why it works

The explicit rule that behavior must stay identical, and the separate list for bugs, stop the model from quietly “improving” logic you did not ask it to touch. Asking for a summary first gives you a cheap check that the model understood the code before it rewrites anything.

Breaking the work into small named steps mirrors classic refactoring practice: each step is easy to review and easy to revert. The risk list points you to the subtle changes, such as iteration order or mutation, that tend to slip through review. Our guide on using AI coding assistants effectively covers how to review generated changes in general.

Tips and variations

• Make sure you have tests before refactoring. If you do not, ask first: “Write characterization tests that capture the current behavior of this code.”
• Apply the steps one commit at a time so a failing test points to a single change.
• Add “Keep the diff under [N] lines” when you only want the most valuable improvements.
• For performance-sensitive code, add “Do not introduce extra allocations or I/O.”
• Run your linter and full test suite on the result; a refactor that looks right can still break an edge case.