Nitpick

What Is a Nitpick?

A nitpick is a minor, non-blocking comment left during code review that addresses cosmetic or stylistic concerns rather than functional correctness. Nitpicks typically cover topics like variable naming preferences, comment wording, import ordering, whitespace formatting, or the choice between two equally valid approaches. The defining characteristic of a nitpick is that the code would work correctly in production regardless of whether the suggestion is adopted.

The term “nitpick” has become a widely recognized convention in software engineering culture. Many teams explicitly label these comments with a nit: prefix so the author immediately understands the comment’s severity and can make a quick judgment call about whether to address it. This labeling practice originated in Google’s internal code review culture and has since spread across the industry.

Nitpicks serve a legitimate purpose when used judiciously. They help maintain codebase consistency, share team conventions with newer members, and surface opportunities for marginally cleaner code. However, when overused or unlabeled, nitpicks become one of the most common sources of friction in code review. Authors feel bogged down by low-value feedback, review cycles drag on, and the important feedback gets buried under a pile of minor suggestions.

How It Works

In practice, reviewers use the nit: prefix to signal that a comment is non-blocking:

# Reviewer comment on a pull request:

# nit: `get_data` is pretty generic -- consider `fetch_user_profile`
# for clarity, since this only queries the user table.
def get_data(user_id: int) -> dict:
    return db.query("SELECT * FROM users WHERE id = %s", user_id)

The author can then decide whether to adopt the suggestion. A common and perfectly acceptable response is to acknowledge the nitpick without making the change:

Acknowledged -- I'll keep `get_data` for now since this function
is scoped to this module and the context is clear from the class name.

Some teams codify the handling of nitpicks in their review guidelines. For example:

• Nitpicks are always optional. The author may address them or not without needing to justify the decision.
• Nitpicks should never block a PR. If a reviewer submits a review with only nitpicks, they should select “Approve” or “Comment,” never “Request Changes.”
• Nitpicks should be labeled. Unlabeled nitpicks are ambiguous and force the author to guess whether the comment is blocking.

On GitHub, a reviewer might submit their review like this:

Looks good overall! A few minor nits below, but nothing blocking.
Approving as-is -- feel free to take or leave the suggestions.

This pattern makes it clear that the PR is approved and the author has full discretion over the suggestions.

Why It Matters

The way a team handles nitpicks reveals a lot about its code review culture. Getting this right has a direct impact on developer velocity and morale:

• Review cycle time. Studies from Microsoft Research and Google show that review latency is one of the biggest bottlenecks in software delivery. When nitpicks require additional review rounds, they add hours or days to the cycle — with no corresponding improvement in code quality.
• Author morale. Receiving a wall of nitpicks on a pull request, especially one that represents significant technical effort, is demoralizing. It can make authors feel that the reviewer did not engage with the substance of their work.
• Signal-to-noise ratio. When important feedback (a security flaw, a race condition, a missing edge case) is mixed in with ten formatting comments, the critical issues are easy to miss. Explicit labeling helps both parties focus on what matters.
• Onboarding velocity. For new team members, nitpicks can serve as gentle introductions to team conventions. A nit: we typically use camelCase for local variables in this repo teaches without blocking.

Best Practices

1. Always prefix nitpicks with nit: or nitpick:. This removes all ambiguity about whether the comment is blocking. The author instantly knows they can exercise judgment.
2. Batch nitpicks into a single approving review. Do not submit nitpicks as “Request Changes.” If the only feedback is cosmetic, approve the PR and let the author decide which suggestions to adopt.
3. Limit the number of nitpicks per review. If you find yourself leaving more than three or four nitpicks on a single PR, consider whether the issues would be better addressed by a linter rule, a formatter configuration, or a team style guide update. Automating style enforcement is always preferable to manual nitpicking.
4. Ask yourself whether the suggestion is worth the author’s time. Every nitpick has a cost: the author reads it, considers it, potentially changes the code, and pushes a new commit. If the improvement is marginal, it may not be worth that cost.
5. Use nitpicks as a teaching tool, not a gatekeeping tool. Frame nitpicks as sharing knowledge (“In this codebase, we typically…”) rather than correcting mistakes (“You should have…”).

Common Mistakes

1. Leaving unlabeled nitpicks. When a comment about naming or formatting lacks a nit: prefix, the author has no way to know whether it is blocking. This leads to unnecessary review cycles where the author addresses every comment defensively, or worse, pushes back on comments that the reviewer considered optional.
2. Bikeshedding through nitpicks. Bikeshedding — spending disproportionate time on trivial details — often manifests as a chain of nitpick comments debating the “perfect” variable name or code structure. If a nitpick sparks a multi-comment thread, it has exceeded its purpose. Resolve it quickly or defer to the author’s judgment.
3. Using nitpicks to enforce personal preferences instead of team standards. A nitpick about brace style only has value if the team has an agreed-upon convention. If the codebase has no style guide or linter rule for the issue, the nitpick is just one person’s opinion — and it should be treated as such. Document the convention or configure the linter; do not use code review as a substitute for tooling.