Nit meaning in code review: comment terms and examples

What does nit mean in code review?

Nit is short for nitpick. A comment that starts with Nit: or nit: points out something small that the reviewer would change but that doesn’t affect whether the code works or whether it can merge. Typical nits:

• A typo in a comment, a log message or a string.
• A name that could be clearer, such as data for a list of invoices.
• Import order, a blank line, or wording in a docstring.
• A slightly shorter way to write the same expression.

Google’s engineering practices describe a Nit as “a minor thing. Technically you should do it, but it won’t hugely impact things.” They also suggest prefixing purely educational comments with “Nit:” when they aren’t needed to meet the standard, and approving a change once it improves the overall health of the code even if it isn’t perfect.

A nit is a promise from the reviewer: this comment won’t hold up the merge. The label lets a reviewer share small improvements without turning them into requirements, and lets the author see at a glance which comments need action. A review where every comment is a nit is, in practice, an approval.

The label only works if it is used honestly. A bug marked as a nit can merge unfixed, and a review with thirty nits buries the one comment that matters. If formatting nits keep coming up, add a formatter or lint rule to CI and stop writing them by hand.

Code review comment terms and abbreviations

The shorthand below appears in pull requests across GitHub, GitLab and Gerrit. Google’s engineering practices define LGTM as what a reviewer says when approving, and label comment severity with Nit, Optional (or Consider) and FYI; the rest are common usage.

GitHub adds its own review states. Comment leaves feedback without approving or requesting changes, Approve signals the change is ready to merge, and Request changes flags feedback the author should address before merging. A draft pull request can’t be merged, and code owners aren’t asked to review it until it is marked ready.

Conventional Comments labels

Conventional Comments turns these habits into a format: <label> [decorations]: <subject>, followed by an optional discussion. The label says what kind of comment it is:

Decorations go in parentheses after the label. (blocking) means the comment should prevent acceptance until it is resolved, (non-blocking) means it shouldn’t, and (if-minor) asks the author to resolve it only if the change turns out to be minor. The spec also lists optional labels: typo:, polish: and quibble:.

suggestion (non-blocking): Extract the retry policy into a constant.

Three handlers use the same 3 attempts and 200 ms backoff. A shared
constant keeps them in step when we tune it.

How to write good code review comments

1. Comment on the code, not the developer. “This loop never exits on a 404” rather than “you broke the retry”.
2. Say what’s wrong and what it causes. Name the input or the path that triggers the problem, so the author can reproduce it.
3. Explain why. Google’s guidance asks reviewers to share the intent or best practice behind a comment, so the author learns the reason and not only the fix.
4. Mark the severity. Use Nit, Optional, FYI or a Conventional Comments label, so required changes stand apart from preferences.
5. Suggest a direction. Fixing the change is the author’s job, but a pointer to the helper to use or a one-line suggested change saves a round trip.
6. Ask real questions. If you aren’t sure something is a problem, say so and ask, rather than phrasing a demand as a question.
7. Praise what’s good. A short note on a clean abstraction or a thorough test tells the author what to keep doing.

Examples: vague comment, better comment

Each better version names the problem, the consequence and a way forward, and says whether it blocks. For more on what to look for before you write a comment, use our code review checklist.

How to use GitHub suggested changes

For a small, exact edit, a suggested change beats a description of one. In the Files changed tab, select the line or lines, open a comment, click the suggestion icon and edit the text inside the suggestion block. The author can apply it straight from your comment.

The author can click Commit suggestion to apply one suggestion, or Add suggestion to batch on several and then Commit suggestions to apply them in one commit. Applying needs write access to the repository; for a pull request from a fork, the author must also allow edits from maintainers. Everyone whose suggestion is included becomes a co-author of the commit.

Suggestions suit renames, typos and one-line fixes. For a change across several files, describe the fix in words instead, since a suggestion only replaces the lines the comment is on.

How to respond to review comments

• Answer every comment. “Done”, “Fixed in the next commit” or a short reason for leaving it tells the reviewer it was read.
• Fix the code, not just the thread. If a reviewer asks what something does, Google’s guidance is to rewrite the code more clearly, because explanations left in the review tool don’t help future readers.
• Disagree with reasons. If you think a blocking comment is wrong, explain why with evidence, such as a test or an issue that tracks the case.
• Ask for another look. When you have addressed everything, a PTAL comment or a re-request from the reviewers list starts the next round.

How HeyDeer labels review findings

HeyDeer posts its findings as a GitHub pull request review, with an inline comment on the lines each finding is about. Instead of nit or blocking, each finding carries a severity that states its impact, plus a category for what it harms. The heading reads like 🟠 High (Reliability): Retry loop never stops on a 404.

The four severities are 🔴 Critical, 🟠 High, 🟡 Medium and 🔵 Low, so the author sees at a glance which findings matter most.

Categories are Security, Correctness, Reliability, Performance and Maintainability. Severity is separate from confidence, how sure HeyDeer is that a finding is real; the feedback scope combines the two to decide what gets posted, and the Concise scope posts Low findings only from repository checks. Teams moving from Claude Code Review can keep their REVIEW.md: its Important maps to Medium or above, and its Nit to Low.

When a comment sits on the lines it replaces, HeyDeer includes a GitHub suggested change you can commit. To decline a finding, reply in its conversation and say why, for example that the behavior is intended. On the next review HeyDeer reads the reply, accepts the decision unless it has concrete evidence it missed something serious, and lists the concern under Declined in discussion. The guide to reading a HeyDeer review walks through each part, and HeyDeer’s AI pull request review covers what it checks.

Sources

1. Google Engineering Practices: How to write code review comments
2. Google Engineering Practices: The standard of code review
3. Google Engineering Practices: terminology
4. Conventional Comments
5. GitHub Docs: Commenting on a pull request
6. GitHub Docs: Incorporating feedback in your pull request
7. GitHub Docs: About pull request reviews
8. GitHub Docs: About pull requests (draft pull requests)