Programmer-Required Code Review checklist

In our blog post on Efficient code review, we recommend that you use a checklist. In code review, Checklist is a great tool-they ensure that the review can be done consistently across your team. They are also a convenient way to ensure that common problems can be found and resolved.

Research from the Software Engineering Institute shows that programmers make 15-20 common mistakes. So by adding these errors to the checklist, you can make sure that whenever these errors occur, you can find them and help you eliminate them.

To help you get started creating a checklist, here are some typical things:

Code Review Checklist

General items

• Can the code work? It has not implemented the expected function, the logic is correct and so on.
• Is all the code easy to understand?
• Does the code conform to the programming specifications you follow? This usually includes the position of the curly brace, the variable name and function name, the length of the line, the indentation, the format, and the comment.
• Are there redundant or duplicated code?
• is the code as modular as possible?
• Is there a global variable that can be replaced?
• Is there any code that is commented out?
• Does the loop set the length and correct termination conditions?
• Is there a code that can be substituted by the library function?
• Is there a log or debug code that can be deleted?

Safety

• Are all data inputs checked (detection of the correct type, length, format, and range) and encoded?
• Where are the third-party tools used, and are the returned errors captured?
• Is the value of the output checked and encoded?
• Can invalid parameter values be handled?

Document

• Is there a comment and describes the intent of the code?
• Do all the functions have comments?
• Is there a description of unconventional behavior and boundary condition handling?
• Is there a document for the use and function of the third party libraries?
• is the data structure and unit of measurement explained?
• Is there a code that is not completed? If so, should it be removed, or tagged with the appropriate tags such as ' TODO '?

Test

• Can the code be tested? For example, do not add too many or hidden dependencies, cannot initialize objects, test frameworks can use methods, and so on.
• Are there tests that can be understood? For example, reach at least the code coverage you are satisfied with.
• Does the unit test really test that the code can do the expected functionality?
• Did you check the "Out of Bounds" error of the array?
• Is there a test code that can be replaced by an already existing API?

You also need to add a list of issues that are likely to cause errors in a particular language.

This checklist intentionally does not list all the errors that may occur. You don't want your list to be so long that no one will ever use it. It's better to just include common problems.

Optimize your Inventory

Use the list as your starting point, and you need to optimize it for specific use cases. A great way to do this is to have your team record the issues that were discovered temporarily during the code review process, and with this data, you can identify the errors that your team often makes, and then you can tailor a review checklist. Make sure you remove any errors that have not occurred. (You can also keep items that are very small, but very critical, such as security-related issues).

be recognized and kept up to date

The basic rule is that any entry on the list must be clear and, if possible, you can make a two-dollar decision on some items. This prevents inconsistencies in judgment. It's a good idea to share this list with your team and make them agree with your list. Similarly, check your list regularly to make sure that the entries are still meaningful.

With a good list, you can increase the number of bugs you find in the code review process. This can help you improve your code standards and avoid the uneven quality of code reviews.

Programmer-Required Code Review checklist