Practice vocabulary for suggesting refactors in code review: simplification, extraction, abstraction opportunities, and nit language.
0 / 5 completed
1 / 5
A reviewer writes: 'This could be simplified to a single map() call.' What kind of feedback is this?
'This could be simplified to...' is a constructive, non-blocking refactor suggestion. It proposes a cleaner equivalent without demanding the author change it — the author can consider it and decide whether to apply it.
2 / 5
A reviewer says: 'Consider extracting this into a function.' What problem are they identifying?
Extracting into a function addresses two problems: inline complexity (a long block of logic is hard to understand at a glance) and duplication (the same logic appears multiple times and should have a single source of truth).
3 / 5
A comment reads: 'This pattern appears 3 times — opportunity to abstract.' What does this mean?
'This pattern appears 3 times' invokes the Rule of Three: once is fine, twice is a coincidence, three times is a signal to abstract. The reviewer is pointing out a DRY (Don't Repeat Yourself) violation and suggesting centralisation.
4 / 5
What does 'nit' mean at the start of a code review comment?
'Nit:' (short for nitpick) signals that the comment is a minor style preference or small optional improvement — not a blocking concern. It tells the author: 'I noticed this, but it won't block my approval if you disagree.'
5 / 5
A reviewer writes: 'This is a nit, but I'd inline this variable — it's only used once.' How should the author interpret this?
A nit comment is an invitation to improve, not a demand. The author can apply it if they agree it improves readability, or add a brief reply explaining why they prefer the current form. Either outcome is acceptable for the review to proceed.