The Perfect PR Review Checklist No One is Talking About
9 out of 10 developer are doing Merge Request reviews wrong 💀.
Will give you a comprehensive checklist at the end of the article that will definitely help you level up the PR Review game.
A PR review isn’t just about checking the code for potential bugs, spelling mistakes, or too many empty lines. It goes way beyond that — it’s about evaluating how the PR fits from both a business and technical standpoint.
For some reason, people underestimate the value of a good PR review. I realized this long before I became a Technical Lead when ensuring all PRs are properly reviewed became one of my most important tasks.
I strongly believe that doing a in-depth code review is absolutely mandatory for engineers, regardless of their level of seniority. And by “in-depth” I don’t mean smashing the approve button without checking a single line from the PR. That’s just irresponsible.
This article is about how to review a PR. Soon will publish another one about the rules of a good Pull Request.
Start with understanding the context
Most of our PRs as engineers revolve around adding or altering business processes. Before reviewing any pull request, make sure you understand the business context first (VERY IMPORTANT!).
A PR review isn’t just about how the code was written — it’s about how it could have been written better, given the business context of the PR.
If the business context isn’t clear from the PR itself, that’s your first red flag. In such cases, reach out to the developer and try to get some context before proceeding with the review.
Don’t be afraid of seeming “toxic” for asking more questions about the business context of a PR.
Is the business flow reasonable?
This one is for more experienced engineers, but anyone can try it — map the PR to the business flow described in the PR. This step is critical because business flow issues can have the most significant impact on the PR.
In some cases, it might need to be completely rewritten if the initial flow is incorrect or inefficient. This can happen for several reasons:
- The PR author is new to the project and lacks knowledge about the system.
- The author is experienced but has blind spots that you might identify.
- Narrow or incomplete thinking.
If you believe the business flow should be revised, consider the next point: the Return on Investment (ROI) rule.
Think about the ROI of your comment
Think twice before leaving a comment. Is the change worth it? Is that single line of code worth fixing? Some projects require deploying changes to a test environment, which might take hours for the author to do. Before commenting, ask yourself: Is this change important enough to justify the effort?
As software engineers, our top priority is delivering business value. That’s what we’re paid for.
If your comment increases the complexity of the task significantly (e.g., from 3 story points to 8), discuss it with the PR author or Technical Lead. Consider adding it as a separate item in the technical backlog so the effort is properly tracked and nobody is forced to work overtime just to fix a comment.
Naming matters
As engineers, we need to design our code to be easily readable, and proper naming plays a critical role in this. After ensuring the business flow is correct, check that variables, classes, services, events, queues, and other infrastructure elements are named appropriately.
If a name is unclear, that’s a red flag. Unnecessarily complex or verbose names can also indicate deeper design issues.
Code conventions
Finally, ensure the code adheres to conventions. While many reviewers focus solely on this aspect, it’s actually the least significant in the bigger picture.
I believe project code conventions shouldn’t be too restrictive because every engineer has their own coding style, which is okay and even welcome. That said, the code must still follow language conventions and general clean code principles. Key points to look out for include:
- Spelling mistakes.
- Too many or too few empty lines between methods.
- Multiple classes defined in a single file.
- Unused imports or usings.
- Not following naming conventions (e.g., PascalCase for classes, camelCase for variables).
- Excessive use of magic strings.
Dealing with the psychological pressure of comments
Your code is not your child. If you’re writing code for a company, the company owns it — that’s stipulated in every job contract. So don’t get too attached.
Second, leaving or receiving comments is in the team’s best interest. It’s a vital part of ensuring quality.
For new joiners, I recommend meticulous PR reviews to help them get accustomed to the project’s coding principles, libraries, and workflows.
A comment under a PR is never inherently bad — unless it’s poorly written.
Ensure your comment does not hurt ones feelings
- Replace phrases like “This method is very inefficient” with “I think we can improve the performance of this method by doing X, Y, and Z.”
- Avoid using “you” in comments, as it might come across as a personal attack
- If the PR is particularly poor, avoid leaving excessive comments. Instead, have a call with the author to discuss it directly. This saves time and allows for real-time feedback.
- If you know someone might take comments personally, consider reviewing their PR in a private chat. This approach often yields better feedback and collaboration.
- Lastly, make your comments clear and actionable. Don’t just write “Improve this.” If you’re suggesting a change, provide a solution or at least outline possible improvements: “This can be optimized by doing X, Y, and Z.”
The Checklist
One by one, in this order:
- I understand the business context of this change;
- I understood author’s business flow and I’m ok with it;
- I am ok with how variables, classes, messages, events are named. They’re self explanatory;
- Code principles and project standards are respected;
- I assessed the ROI of my comments;
- My comments are impersonal and I care about author’s feelings;
- I notified the PR author about my comments
- I approved the PR once all comments are fixed and I’m ok with it.
