The Art of Code Review: Be Kind, Be Clear, Be a Code Whisperer

April 16, 2025 • Code Review

Let's face it: reviewing Pull Requests is the broccoli of development. You know it's good for you, but it's not always fun — unless you know how to spice it up and do it right.

If you've ever dropped a passive-aggressive comment or gotten a soul-crushing "This doesn't scale" on your PR, this article is for you.

Code review compliment sandwich illustration Image from https://geek-and-poke.com/

Being a good PR reviewer isn't just about catching bugs. It's about collaboration, clarity, empathy, and sometimes — yes — talking to your AI buddy, GitHub Copilot.

✅ Best Practices for Being a Kickass Reviewer

🍞 Start with a Compliment Sandwich

Don't go in guns blazing. Start by acknowledging what's good.

“Nice use of useCallback here—makes the component super snappy!"
"But hey, this map inside the render could be memoized."

Use useCallback for memoizing functions or useMemo for other values.

People aren’t merge bots — they’re humans who just spent hours staring into the abyss of nested ternaries.

🎬 Read the PR Description Like It’s the Plot Summary of a Nolan Movie

Before diving into code:

  • What’s the goal?
  • What problem is being solved?
  • Are there screenshots, test plans, or linked issues?

If the PR has no description, request it politely:

Hey! Could you add a quick summary of the changes here? Helps reviewers stay on the same page. 🙌

🏷️ Label Your Comments Like a Pro

Not all comments carry the same weight. Help your teammate prioritize by labeling your feedback clearly. It saves confusion, reduces guesswork, and makes your review feel thoughtful instead of chaotic.

Use labels like:

  • Nit — Minor things like formatting, naming, or micro-optimizations. Non-blocking.

Example Nit Image

  • Suggestion — Optional improvements that could enhance readability, performance, or structure.

Example Suggestion Image

  • Blocker — Something that must be fixed before merging (e.g., bugs, regressions, broken logic).

Example Blocker Image

  • Question — Points that need more clarity or discussion before moving forward.

Example Question Image

This lets the PR author know what to fix now, what to consider later, and what just sparked a curious thought. Plus, it shows you’ve taken the time to organize your feedback — not just dumped it.

🕵️‍ Ask, Don’t Tell (Unless It’s a Security Risk)

Bad:

Change this, it’s wrong.

Better:

Would it make sense to use a useMemo here instead? Might avoid re-renders.

You’re not a code cop. You’re a curious teammate.

🔪 Don’t Nitpick to Death

Nobody wants 15 comments like:

  • “Missing comma.”
  • “Extra line break.”
  • “Variable could be shorter.”
  • “Missing new empty at EOF”

That’s what linters and Prettier are for. If it’s not breaking anything, breathe. You can always open a PR to address linters and Prettier changes.

🤖 Use Copilot to Review? Oh Yes, You Can.

Copilot isn’t just for generating code — it can help review too:

  • Select a function and ask Copilot:

What’s this doing?

  • Ask for alternatives:

Can this loop be optimized?

Copilot won’t replace you, but it’s like having an over-caffeinated junior dev whispering tips.

❌ Reviewer Red Flags (Aka Don’t Be That Dev)

  • Drive-by LGTM 🚀
    Two minutes on a 500-line PR? Nah. That’s not trust. That’s neglect.

  • Tone-Deaf Comments

"This is a terrible implementation."
Try
“This approach might introduce issues — what about using X instead?”

  • PR as a Battleground
    If you strongly disagree, talk it out in a call. Text lacks tone. Even “?” can sound passive-aggressive.

  • Holding It Hostage
    Don’t vanish for days. If you can’t review, say so. Blocking someone’s merge with ghost energy = developer sin.

🙌 The Gentle Ask: Requesting Changes Without Crushing Souls

Instead of:

Fix this.

Try:

This could be a bit cleaner — what do you think about extracting this into a utility?

Instead of:

Tests are missing.

Say:

Could you add a test for the loading state? Would help catch regressions later.

You’re not just a reviewer. You’re a mentor, a peer, a collaborator.

✅ Approve with Comments & Close the Loop

Approve… and Suggest
You don’t have to block a PR just to leave a suggestion. Approving with comments is a baller move — it says:

You’re good to go, but here’s a thought you might want to consider later.

It builds trust, avoids unnecessary cycles, and keeps the team moving.

Say Thanks After Revisions
When someone makes updates based on your feedback, don’t just vanish into the merge button. A simple:

“Thanks for the update!"
"Appreciate the quick fix 🙏"

…goes a long way. It closes the loop and makes people feel seen, not just managed.

Example Appreciation Comment

💎 Bonus Tips to Level Up Your Review Game

🚀 Final Thoughts

A good reviewer is less about being right and more about being kind, constructive, and consistent. Good PR reviews build trust, prevent bugs, and make everyone better.

So next time, think less “gatekeeper” but more “collaborator.”

The best code isn’t just clean — it’s reviewed with care.