5 exercises on the language of suggesting refactors in code review — the exact verbs and phrasal verbs developers use to recommend cleaner, clearer code.
Key patterns
extract a method / pull out a helper → split code out
simplify the logic / reduce duplication → DRY goals
tidy up → small cosmetic cleanups
rename for clarity → give a self-explanatory name
dead code → remove unused / unreachable code
0 / 5 completed
1 / 5
A reviewer sees a long function doing several things and wants to recommend pulling part of it into its own named function. What is the standard refactoring collocation?
Extract a method — the foundational refactoring:
"Extract Method" (Martin Fowler's catalogue) means taking a fragment of code and turning it into its own named function/method.
"Let's extract a method called validateInput()."
"This block could be extracted into a separate function."
"Extract the date formatting so it can be reused."
The extract family:
extract a method / function — pull code into a named routine.
extract a variable — name a sub-expression for clarity.
extract a class / module — split out a larger responsibility.
Why the distractors fail:remove means delete; export exposes a symbol from a module (different concept); expand means enlarge. The precise verb for splitting code out is extract, and IDE refactor menus literally label it "Extract Method/Function".
2 / 5
The same validation appears in three different files. A reviewer wants to suggest consolidating it. Which two collocations best express the goal?
Simplify the logic & reduce duplication — the DRY goals:
When code is repeated or convoluted, reviewers ask the author to simplify the logic and reduce duplication (the DRY principle: Don't Repeat Yourself).
"Could we reduce duplication by sharing one helper?"
"This conditional is hard to follow — can we simplify the logic?"
"DRY this up by extracting the common path."
Related collocations:
consolidate repeated code into one place.
streamline a process / a function.
untangle complex / spaghetti logic.
"DRY it up" — informal verb from the acronym.
Why these verbs: we simplify logic (not "shorten/compress/flatten" it) and reduce duplication (not "delete/cut/drop" it). These are the exact phrases used in style guides and review comments, so they read as native.
3 / 5
A reviewer leaves a friendly, low-priority note asking the author to clean up minor formatting and stray whitespace. Which phrasal verb is idiomatic?
Tidy up — the everyday cleanup phrasal verb:
To tidy up (BrE-favoured but widely used) means to make small, cosmetic improvements: sorting imports, removing blank lines, fixing indentation.
"Quick tidy-up: sort the imports alphabetically."
"I'll tidy up the formatting before merging."
"nit: tidy up the trailing whitespace here."
Cleanup vocabulary:
tidy up / clean up — general small improvements.
polish — final cosmetic touches.
format the code — apply consistent style (often automated via Prettier/gofmt).
Particle matters: the correct phrasal verbs are tidy up and clean up — not "tidy off" or "clean over". "Sweep up" is too literal for code. A tidy-up is usually a non-blocking nit, so pair it with softening language like "when you get a chance".
4 / 5
A variable named d is confusing. The reviewer suggests a clearer name, and also recommends moving a repeated calculation into a small reusable function. Which two collocations fit?
Rename for clarity & pull out a helper:
Good names and small reusable functions are core to readable code.
rename for clarity — give a symbol a self-explanatory name: "Renamed to daysElapsedfor clarity."
pull out a helper — extract a small utility function: "Let's pull this out into a helper so both call sites share it."
Related phrases:
a helper (function) / a utility — small, reusable routine.
pull out / extract — both mean lift code into its own unit.
"name things clearly" — a frequent review refrain.
Why the others fail: we rename for clarity/readability, not "shortness/speed"; you pull out a helper (not "push in" or "tear out"); and you rename code symbols (not "retitle" them — that's for documents). These pairings are exactly how engineers phrase refactor suggestions.
5 / 5
A reviewer spots a function that is never called and an unused import left behind after an edit. What is the precise term, and the natural verb to act on it?
Dead code — the precise term for unreachable code:
Dead code is code that is never executed or never used — unreachable branches, unused functions, leftover imports. The natural action is to remove (or delete) it.
"This is dead code — safe to remove."
"Let's strip out the dead code the linter flagged."
"Unused import — dead code, please remove it."
Related vocabulary:
unreachable code — can never run (e.g. after a return).
unused variable / import — declared but never referenced.
commented-out code — disabled but left in; usually should be removed (git keeps history).
Why "dead code": it is the established industry term, surfaced by linters and static analysers. "Idle", "spare", or "old" code aren't standard, and you remove dead code rather than "archive" it — version control already preserves the history.