Sample Code Review Checklist

Code review is one of the most important steps in nowadays' SDLC. In some companies, the unreviewed code wouldn't merge. The purpose of code review is not only about finding the missing parts or checking the other developer's code, but also about learning the logic behind the implementation, learning more about business logic and improving the software quality of the team.

There aren't any strict rules for code reviews. For your team, you may say that one reviewer is enough, whereas, for a different team, all of the developers are required for review. It's up to your team and your team's dynamics. The team should communicate with each other and agree on a code review checklist. This checklist can contain a set of rules including checking business logic implementations, doing performance checks, checking code format and best practices, etc.

Below is a sample code review checklist, which can be helpful when thinking about the parts of the code that need the most focus. Feel free to add or take away steps that you feel will be beneficial to your company!

• Be careful about code format. The team needs to agree on a format and everyone in the team should use that format.*
• Ensure that proper naming conventions (Pascal, CamelCase, etc.) have been followed. If you code Java, then you need to follow Java naming conventions. (E.g. Class names should start with capital letters, method names start with lowercase letters, etc.)
• Remove comments if they give no information! Comments should explain why the code is written. Comments may also be used if there are complicated business rules or workaround solutions. Other comments should be removed.
• Attention should be paid to the architectural approach of the written code. The code should split into multiple layers. The MVC design pattern must be maintained and any parts that do not fit the layered architecture should be corrected.
• The code should not disrupt the existing architectural structure. Code that does not preserve the existing structure must be corrected.
• If there is a hard-coded variable in the code, it must be assigned to a constant or a configuration variable.
• Check that similar variables can be grouped under an enum.
• Verify that existing libraries/classes are used instead of writing code from scratch.
  • Anything should be removed if another library is used that does the same work as the existing libraries in the application.
• The purpose of the written code should be understood from the related issue** or the code itself. If no code belonging to the requested business rule has been written, it must be corrected.
• The code blocks should be concise. Make sure that the code is separated into blocks and each block has its own and only one responsibility. (Single Responsibility Principle)
• It's better to check whether SOLID principles are applied or not.***
• Code duplication should be checked, if there is a code written for the same purpose in the project, that code should be used or changed so that it can be used. (Don't Repeat Yourself)
• Edit any unreadable and not properly named code. The method or class name should describe its work correctly.
• Be sure that exceptions and errors are handled and logged properly. If the method returns an error code, check that if it describes the error properly.
• The code should be checked for security as possible as you can. Be aware of SQL Injection, XSS, Man in the middle, etc. Specifically, check the implementation behind the HTTP 3xx redirects.
• Performance controls should be done. Possible null pointer exceptions, cache errors, possible lazy initialization exceptions, String + String usages instead of StringBuilder should be fixed.

The above checklist is optional and you're free to change, remove, and add the elements. This checklist is here for you to be inspired and get a code review approach. The main purpose of code reviews is to improve your codebase, improve your team's development skills, share knowledge, communicate, and —finally— write good code.

It will take some time for a reviewer to review code effectively, but after some experience, the reviewers will review code quickly and efficiently!

Happy code reviews!

*: As Uncle Bob said in Clean Code, Code formatting is important. It is too important to ignore and it is too important to treat religiously.

**: Issues should be tracked by an issue tracking system. And it's better not to code anything without an issue.

***: SOLID principles is a highly deep object to discuss. Here you can start https://en.wikipedia.org/wiki/SOLID