3,350 reads

A Code Review Checklist to Focus on the Important Parts

by Michaela GreilerApril 1st, 2020

Too Long; Didn't Read

A Code Review Checklist to Focus on the Important Parts of the Software Engineering Unlocked Podcast. Michaela Greiler: Code reviewers who use checklists outperform code reviewers who don’t. A code review checklist can make your code review practice so much more beneficial to your team and significantly speed-up code reviews. As the author of the code change, follow the code review best practice and be your own reviewer first! A great checklist directs your attention to the important and most valuable issues first.

Companies Mentioned

Coin Mentioned

featured image - A Code Review Checklist to Focus on the Important Parts

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

Does this code change do what it is supposed to do?

Can this solution be simplified?

Does this change add unwanted compile-time or run-time dependencies?

Was a framework, API, library, service used that should not be used?

Was a framework, API, library, service not used that could improve the solution?

Is the code at the right abstraction level?

Is the code modular enough?

Would you have solved the problem in a different way that is substantially better in terms of the code’s maintainability, readability, performance, security?

Does similar functionality already exist in the codebase? If so, why isn’t this functionality reused?

Are there any best practices, design patterns or language-specific patterns that could substantially improve this code?

Does this code follow Object-Oriented Analysis and Design Principles, like the Single Responsibility Principle, Open-close principle, Liskov Substitution Principle, Interface Segregation, Dependency Injection?

Logic Errors and Bugs

Can you think of any use case in which the code does not behave as intended?

Can you think of any inputs or external events that could break the code?

Error Handling and Logging

Is error handling done in the correct way?

Should any logging or debugging information be added or removed?

Are error messages user-friendly?

Are there enough log events and are they written in a way that allows for easy debugging?

Usability and Accessibility

Is the proposed solution well designed from a usability perspective?

Is the API well documented?

Is the proposed solution (UI) accessible?

Is the API/UI intuitive to use?

Testing and Testability

Is the code testable?

Does it have enough automated tests (unit/integration/system tests)?

Do the existing tests reasonably cover the code change?

Are there some test cases, input or edge cases that should be tested in addition?

Dependencies

Does this change require updates outside of the code, like updating the documentation, configuration, readme files? If so, was this done?

Might this change have any ramifications for other parts of the system, backward compatibility?

Security and Data Privacy

Does this code open the software for security vulnerabilities?

Are authorization and authentication handled in the right way?

Is sensitive data like user data, credit card information securely handled and stored?

Is the right encryption used?

Does this code change reveal some secret information (like keys, usernames, etc.)?

If code deals with user input, does it address security vulnerabilities such as cross-site scripting, SQL injection, does it do input sanitization and validation?

Is data retrieved from external APIs or libraries checked accordingly?

Performance

Do you think this code change will impact system performance in a negative way?

Do you see any potential to improve the performance of the code?

Readability

Was the code easy to understand?

Which parts were confusing to you and why?

Can the readability of the code be improved by smaller methods?

Can the readability of the code be improved by different function/method or variable names?

Is the code located in the right file/folder/package?

Do you think certain methods should be restructured to have a more intuitive control flow?

Is the data flow understandable?

Are there redundant comments?

Could some comments convey the message better?

Would more comments make the code more understandable?

Could some comments be removed by making the code itself more readable?

Is there any commented out code?

Experts Opinion

Do you think a specific expert, like a security expert or a usability expert, should look over the code before it can be committed?

Will this code change impact different teams? Should they have a say on the change as well?

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.