Effective Code Review. Code reviewer checklist.

Vlad Antsitovich
3 min readDec 30, 2021

Why does code review matter?

We all want to make the best products/projects and etc. Public discussion can help us to improve our code quality, check if code is understandable, ensure code does what it’s supposed to, also it’s a big opportunity to share knowledge.

What we can do for the best code review?

For the whole team to avoid any discussion about code style and some sharp edges in code it’s better to add tools that help you to avoid these:

  • Engineering style guide
  • Formatting and linting
  • Unit and integration tests
  • Git Hooks for automating all issues above
  • Static types
  • CI for testing, linting, and compiling (Git Hooks)
  • Pull request templates

For author

You should provide PR for each feature separately, and if it’s a big feature brake it up into a series of smaller PR (it will help your reviews to focus on your small changes and make it easier to review them). Keep it simple and small. If your PR will be big it will introduce complexity and no one want to understand what’s going on in it.

Good pull request templates help you to provide all information to help code reviewers as much as possible.

NOTE: also providing comments in your code will help reviewers to understand your changes faster. For example why and what your code do.

After PR was successfully sent on review. Don’t be lazy and review your code by own. The first reviewer should be you!

Here is code reviewer checklist for you:

  • Is code easy to understand? If not and I don’t know how to do this — add comments or documentation to this.
  • Are functions too big? And can we split it into small chunks?
  • Is code easy to maintain?
  • Is code written following the coding standards and team style guide?
  • Is the same code duplicated?
  • Test coverage
  • Before rejecting or approving notice good parts

For reviewer

I suggest you take a break before you will review any PR.

After brake just simply read RP and don’t touch your keyboard. Try to understand the decisions the author made (understand the common patterns, understand the architecture choices) it will help you in a couple of ways. So one it’s possible that the entire PR is total need be redone. Reading through PR first also allows you to see the patterns or issues that repeat and to avoid commenting on each and just bundle that all together into one summary comment “I noticed in a couple of places you did this patter …”.

Provide actionable feedback. Think about how can WE improve this code. Maybe in some cases, WE don’t have the solution of how to make it better.

Know your limitations. Maybe you don’t have enough knowledge to confidently give approval. It’s totally fine. Don’t give a green mark because you asked for it.

NOTE: Offer positive feedback during code reviews!

--

--