Refactor a Function Without Lying

Retrieval Prompts

1. What does it mean for a function to do one thing?
2. Why are boolean flags and long parameter lists often warning signs?
3. What makes a side effect misleading rather than acceptable?
4. Why can boundary wrappers improve function cleanliness?

Refactor Checklist

Before changing code, answer:

• What behavior must stay identical?
• Which lines are validation, which are core logic, and which are I/O or boundary work?
• Does the function name match what the function really changes?
• What is the smallest safe extraction?

Common Mistake Check

Do not split a function into three helpers that still depend on hidden shared state.

Do not rename a function to sound pure if it still mutates data.

Do not bury errors by catching everything and returning a default.

Mini Application

Take one function with at least one of these smells:

• more than 20 lines
• four or more parameters
• a boolean flag
• visible side effects not revealed by the name
• mixed validation and core logic

Refactor it in at least three small steps. After each step, write one sentence saying what became more honest.

Evidence Check

You are done only when:

• the final function names expose the main steps
• the side effects are explicit
• the error path is clearer than before
• you can describe each refactor step independently