A code review checklist, as well as clear rules and guidelines around code reviews, can make your code review practice so much more beneficial to your team and significantly speed-up code reviews.
Studies have shown that code reviewers who use checklists outperform code reviewers who don’t. So, consider using a code review checklist, whether you are a new developer or already an experienced one.
Be Your Own Code Reviewer
Code review checklists are not only something for the code reviewers. Instead, as the author of the code change, follow the code review best practice and be your own reviewer first!
So, before sending out the code for review, make sure that:
- The code compiles and passes static analysis without warnings
- The code passes all tests (unit, integration and system tests)
- You have double-checked for spelling mistakes and that you did a cleanup (comments, todos, etc.)
- You outlined what this change is about including the reason for the change and what changed
Apart from that you, as the code author, should run through the same code review checklist as the reviewer.
Code Review Checklist for Code Reviewer
As a code reviewer, it is your task to look for the most important issues first. It is easier to get hung-up in nitpicking. But, that's not good. In one of our large studies at Microsoft we investigated what great code review feedback looks like. We clearly saw that comments revealing larger structural or logical problems are perceived as much more valuable than comments that focus on minor issues.
This is where code review checklists come into play. A great checklist directs your attention to the important and most valuable issues. Below you find a checklist that I use also during my code review workshops. It is divided into ten separate sections. Each section guides you through several questions. So, let's start:
Implementation
Logic Errors and Bugs
Error Handling and Logging
Usability and Accessibility
Testing and Testability
Dependencies
Security and Data Privacy
Performance
Readability
Experts Opinion
Well, that’s it. You looked and thought about the most pressing issues. Congratulations!
Now, one of the exercises that I do in my code review workshops is to reflect with the participants on the code review checklist by answering three questions:
- Which parts of the code review checklist are you focusing on the most?
- Which parts do you tend to neglect?
- Do you believe some of those points are more important than others? Why?
But what about coding styles and conventions?
Maybe during this exercise, you realized that I did not check whether the code follows the right coding style. So, is that not important?
Short answer, it is important. Crystal-clear coding style guides are the only way to enforce consistency in a codebase. And, consistency makes code reviews faster, allows people to change projects easily and keeps your codebase readable and maintainable.
Google is a great example of doing this right. And this surely allows Google to have one of the fasted code review turnaround times.
As a starting point, I recommend using the ready-made coding styles for many languages from Google.
It is important to set the ground rules, but make sure to do that once and for all. Don’t argue about it on an ongoing basis.
Cristal-clear coding styles can speed-up your code reviews. But, only if you automatically enforce them via tooling. (Click to Tweet)
Automate what can be automated
But, once you decided how your codebase should look like, take the time to install and configure tooling properly so that code formatting becomes a matter of pressing a button.
Also, there is much more you can do. Use static analysis tools to free up the time of your human code reviewers. It is worth the initial effort.
Don't make your reviewers check for issues tooling could detect more reliable and much more cost-effective. (Click to Tweet)
Be respectful, humble and kind
Finally, the quality of the code review feedback does not only depend on WHAT you are saying, but also on HOW you are saying it. So, the best code review feedback is worth nothing when it isn't carefully phrased, humble and kind. For starters, phrase your feedback as suggestions instead of demands. For example, instead of writing “Variable name should be removeObject.” say “What about calling the variable removeObject?”. For more input read my article on how to give respectful code review feedback.
There is more for you…
You can download the whole checklist as PDF or use the image below. Another resource that might be super valuable for you is my free code review e-book.
Finally, did you know that I help teams make code reviews their superpower? Check out my remote code review workshop.
Previously published at https://www.michaelagreiler.com/code-review-checklist/