Reduce errors with the Code Review checklist

In our article on effective code reviews, we recommended using a checklist. Checklists (checklists) are a great thing in a review: they ensure that the review really goes through your team. They also contribute to the identification and resolution of common difficulties.

A study by the Software Engineering Institute shows that programmers make 15-20 common mistakes. By adding such errors to the checklist, you can be sure that you will notice them at the time of their appearance and help to get rid of them for a long time.

So that you have something to start from, here is a list of typical points:

CodeReview Checklist

General

• Does the code work? Does he fulfill his direct duties, is logic correct, etc.
• Is the code easy to understand?
• Does the code match your coding style? This usually refers to parentheses, variable and function names, line lengths, indentation, formatting, and comments.
• Is there redundant or duplicate code in the review?
• Is the code as independent as possible?
• Is it possible to get rid of global variables or move them?
• Is there any commented code?
• Do loops have a set length and correct termination conditions?
• Can something in the code be replaced by library functions?
• Can part of the code intended for logging or debugging be deleted?

Security

• Are all input data checked (for the correct type, length, format, range) and encoded?
• Are errors handled when using third-party utilities?
• Is the output checked and encoded ( approx. Transl .: for example, from XSS )?
• Are invalid parameter values ​​handled?

Documentation

• Are there any comments? Do they reveal the meaning of the code?
• Are all functions commented out?
• Is there any unusual behavior or description of borderline cases?
• Is the use and functioning of third-party libraries documented?
• Are all data structures and units described?
• Is there any incomplete code? If there is, should it be deleted or marked with a marker like “TODO”?

Testing

• Is the code testable? For example, it should not contain too many dependencies or hide them, test frameworks should be able to use code methods, etc.
• Are there any tests, and if so, are they sufficient? For example, they cover the code to the right extent.
• Do unit tests actually verify that the code provides the required functionality?
• Are all arrays checked for “going out of bounds”?
• Can any test code be replaced using the existing API?

You may also want to add to this checklist any things specific to your language that might cause problems.
The checklist does not knowingly cover all possible problems. You do not need a checklist that is so long that no one uses it. It is best to cover only general questions with it.

Optimize your checklist.

This checklist can be used as a starting point: you need to optimize it for your specific scenarios and problems. A great way to do this is to note issues that arise in your team during code review for a short time. With this information you will be able to find the most common team errors, and then add them to your checklist.
Do not be afraid to throw out from the checklist those elements that are not suitable for you (you may want to leave rarely encountered, but still critical points - for example, related to security).

Start using and keep up to date

As a rule, any checklist items should be specific and, if possible, give you a definite answer to your question. This helps to avoid inconsistency of judgment.
Another good idea is to share the list with your team and get their agreement with its contents. Periodically review the checklist itself to verify that each item in it is still relevant.
Armed with a good checklist, you can increase the number of defects detected during code review. This will allow you to improve the coding standard and avoid poor quality reviews.
To learn more about the code review, you can check out the video on our page .