Code Review: Best Practices and Checklist

This story explores code review best practices by examining common sins in code review processes and how to prevent them. At the end, you’ll get a code review checklist. My experience, observation, and self-reflection inspired the story. What is code review? It is a collaborative process in which developers examine and critique each other’s code changes to identify errors, ensure consistency, and improve overall quality.

Forgive me, Father, for I have sinned. I’ve walked a dark path where code review stopped blessing the team and turned into the joy of sins, conflicts, and the spreading of evil. 

1 The Sin of “Redundant Spaces”

What it looks like: I’m focusing on the code’s formatting, ignoring all the changes, and concentrating on the things that do not bring business value. I am not looking for problems. I’m looking for redundant spaces.

Why it’s bad: It wastes time and annoys the author. Real problems stay undiscovered. 

How to repent: Discuss with a team following code style and using automated formatting tools. Let the computer handle these style issues and focus on architecture and logic. 

2 The Sin of “Subjective Taste Wars”

What it looks like: I carry my cross on this crusade, delivering knowledge for everyone to accept. This solution shouldn’t be done in this way. Believe in SOLID and TDD, and you’ll get my blessing. I’m spreading and fighting for my personal preferences without referencing code conventions or pointing to potential benefits.

Why it’s bad: It sparks conflicts, extends review cycles, and destroys trust. Code review should be about overall quality, not personal whims.

How to repent: Define team-wide standards (code conventions). Follow code conventions consistently and give feedback based on this, or point to the benefits. 

3 The Sin of “Vague or Hostile Feedback”

What it looks like: I’m right, my words are True, you’re never a good coder, and your solution is disgusting as hell. Why do you do this?

Why it’s bad: A toxic discussion about the solution, pointing directly at the author, develops a bad atmosphere in the team. The author feels confused and offended, and loses motivation. Collaboration, constructive feedback, and respect for teammates are keys to success.

How to repent: Be specific: “This function may cause memory leaks. Let’s try to adopt your solution using this cool guideline about memory optimization”. Following code review best practices means offering actionable suggestions while respecting the author and their work. He put effort into developing a solution and wanted to hear constructive comments about the solution, not himself. Remember: The author’s code is not the author.”

4 The Sin of “Massive PRs” 

What it looks like: I’m very excited about my code. I was so productive that I sent an insanely large pull request for review. My teammates are skilled and could review it quickly!

Why it’s bad: Reviewing big changes is hard. Reviewers miss essential details about implementation and want to finish it faster. As a result, the quality of the code review process decreases, problems are overlooked, and frustration rises.

How to repent: Break down big changes into small ones. Focus on making the process of review easier. Put yourself in a teammate’s shoes. You don’t like reviewing thousands of lines of changes that you don’t like, but why do you keep doing this? 

5 The Sin of “Scrolling Over The Code”

What it looks like: I’ve received a pull request. Let’s give the code a quick once-over and wrap up this review. I’m leaving a couple of comments that I believe illustrate my reasoning.

Why it’s bad: Code review is designed to catch bugs earlier and improve solutions, not just to check a box. Surficial reviews miss the issues, leading to more significant trouble. 

How to repent: Find time to read changes from pull requests carefully. If you can’t, communicate with the author and ask for time or switch to another teammate. 

6 The Sin of “Ignoring Colleagues’ Time”

What it looks like: I received a review request, but I keep putting it off. I’ll do this later, maybe tomorrow or next week.

Why it’s bad: Code review is often a blocking step in the SDLC (Software Development Life Cycle), which blocks the next releases, slows down the team, and demotivates the author. 

How to repent: Prioritize code review, as mentioned in the previous sin—find a time in your schedule and return to the author if you can’t find a time. With the earlier feedback, the author could reassign the pull request. Quick feedback is key to healthy workflows and a positive team spirit. 

7 The Sin of “Ignoring the Comments”

What it looks like: The reviewer points out a real problem or a valuable improvement, but I either forget about it or apply a half-baked fix.

Why it’s bad: The review process loses meaning if comments are left unattended and bad solutions are deployed to production. Reviewers could be demotivated as a result.

How to repent: After discussions, address the issues or explain clearly why you disagree with the comment, but make sure you hear what the reviewer wants. Code review is a team effort, and decisions reached in the review should be reflected in the final code or discussed. 

Code Review Checklist

Use this code review checklist to align with the provided best practices

For the Author

• Is this pull request concise and focused, or am I burdening my teammates with an impossibly large review?
• Have I thoughtfully addressed every comment and implemented the agreed-upon changes, or am I letting valuable feedback go unresolved?

For the Reviewer

• Am I focusing on the architecture and logic where real problems hide, or am I wasting time on formatting that a linter should fix?
• Is my feedback grounded in our team’s conventions and objective benefits, or am I waging a war over personal taste?
• Is my feedback constructive and specific, focusing on the code, or is it vague and hostile, demoralizing the author?
• Am I giving the code the careful attention it deserves, or am I just scrolling through and risking that bugs will slip into production?
• Am I prioritizing this review to unblock my teammate, or am I letting it linger and slow down the entire team?

Code Review Best Practices: Final Thoughts

Code review is one of the best techniques for keeping your codebase current, enforcing internal standards, and catching issues early in the SDLC. When done right, it’s a powerful tool that drives quality and collaboration. 

Simply integrating code review for integration can spread chaos in your team, lowering performance and killing motivation. Instead, invest in an improved review process that incorporates code review best practices with an agreed checklist, valuing quality over speed, and turning every review into an opportunity for improvement and shared learning

That’s all for now. If you’re interested in IntelliJ plugin development, follow me on LinkedIn to learn about new articles. If you are interested in the mental health topic, read my related article: You Don’t Need a Pet Project to Be a Good Dev: How I Beat FOMO