Code Review best practices

Follow clear guidelines for code review to help improve code quality and products

Jul 23, 2022 4 min read

This is a condensed and lightly remixed version of Google’s must-read Code Review Developer Guide.

Why review

The purpose of code review is to make sure code quality increases over time and to keep delivering value to customers/stakeholders.

Why do we review each other’s code?

What to look for

Code reviews should look at:


Follow these key principles, in order:

How to write code review comments

When reviewing someone else’s code, always assume competence and goodwill.

Try to always:

When reviewing someone else’s code, always assume competence and goodwill.

Critique the code and never the person. Some examples:

If you see something clearly wrong, it most likely comes from a lack of information, not from an inability. Use the opportunity to explain, teach, and lead to correct solutions.

If you see something you like, you can comment on that as well. Learn something new? Let them know. Encourage more great code/change by praising it.

How to write a good changelist / pull request (for code authors)

The first sentence of a changelist (pull request) describes what’s actually being done.

The rest of the description explains why the change is being made and gives the reviewer a lot of context.

First Line tips:

Some examples:

Remember that the changelist description is a public record of what change is being made and why it was made. It will become a permanent part of our version control history, and will possibly be read by hundreds of people other than your reviewers over the years.

How to handle reviewer comments (for code authors)



Read more posts like this in the Software Engineering Toolbox collection.
Visit homepage
comments powered by Disqus