What a nit means in code review, and how to give one without starting a fight
Othman Shareef · October 14, 2026 · 4 min read · Code Review Glossary
In code review, a nit is a minor, non-blocking comment: a small point about style, naming, or polish that the reviewer wants to mention but does not consider a reason to hold up approval. The word is short for nitpick.
Nit code review meaning: what does the prefix signal?
A review comment carries two messages: the observation itself, and how much the reviewer cares. The nit: prefix makes the second part explicit. It says: I noticed this, I would do it differently, and I am approving either way. That framing is the whole value. Without it, the author has to guess whether a comment about a variable name is a passing thought or a condition for approval, and guessing wrong in either direction wastes a round trip. The Conventional Comments spec generalizes this idea into a full vocabulary: labels like suggestion, question, issue, and nitpick, plus decorations like (non-blocking) that make severity unambiguous. You do not need the whole system to benefit; even adopting nit: alone removes a surprising amount of friction.
Nit etiquette for reviewers
A nit is a courtesy, and it stays one only under a few rules:
- Mean the label. If you would withhold approval over it, it is not a nit. Do not write
nit:and then argue three replies deep. - Say the fix, not just the flaw. A nit that names the preferred spelling costs the author seconds; a vague one costs a guess. Our guide to review comments that land applies doubly to small ones.
- Ration them. Ten nits on a solid change read as hostility, however polite each one is. We covered the failure mode at length in our piece on code review nitpicks.
- Automate the recurring ones. A nit you have typed three times is a linter rule waiting to be written. Machines nitpick for free and nobody resents them.
Nit etiquette for authors
Non-blocking does not mean ignorable. The gracious move is to fix cheap nits in the next push, reply briefly to the ones you are declining, and resolve the threads either way so the reviewer is not left wondering. Silently skipping every nit trains reviewers to escalate small feedback into blocking feedback, which makes reviews slower for everyone. Treat nits as free polish from someone who read your code closely, because that is what they are.
There is a mechanical courtesy here too: on GitHub, who resolves the thread matters. For a nit you fixed, resolving it yourself with a quick done is fine. For one you are declining, leave the thread open long enough for the reviewer to see your reasoning before it disappears. We cover the finer points in our guide to resolve conversation etiquette, but the principle is short: a nit deserves an acknowledgment, not a burial.
When is a nit not a nit?
The label gets misused in both directions. Reviewers sometimes soften real problems with it: a swallowed exception or an off-by-one is not a nit, and prefixing it as one buries a defect under politeness. The reverse misuse is the blocking nit, where a style preference arrives labeled as small but is defended like a design principle. A quick test for both: would this comment survive being ignored? If ignoring it risks a bug, drop the prefix and say so plainly. If ignoring it costs nothing but your aesthetic satisfaction, keep the prefix and let it go. The nit convention works precisely because the label is honest; spend it carelessly and your reviews lose their signal.