Code review represents the best way to maintain a high level of code quality. The code review functions not only as a way to excise bad code, but also as an exercise in which coders can improve their skills, learn and optimize their work. Code giants, like Google, now use code review on everything added to the codebase.
But most coders don’t run through a checklist on the regular. At least, not a formal one. And not a check list that’s uniformly used by all coders and reviewers. Instead, coders tend to rely on informal mental checklists that they’ve created for themselves. Yet, this checklist may have serious flaws…
By adopting a formal checklist, reviewers can focus on the important components. They can then make changes accordingly. Checklists also enable reviewers to ensure that they don’t omit anything of importance.
Top tips for building an effective code review checklist
1. Mind the length. In building a code review checklist, it is important to consider the number of tasks or steps included on it. If a checklist is too short, it’s unlikely to be a true checklist and to cover the important stuff. But if a checklist is too long, it will simply be ignored.
Right-size your checklist. As a rule of thumb, include 3-5 major issues and another 7-10 additional entries focused on smaller issues.
2. Start with basics. Many code review checklists are already out there. Some are long lists of tedious questions. Others are broad topics that you should make sure to consider. Most of those issues are simply good design principles that any coder should retain knowledge of and manage while developing code. It makes sense that those would be the focus of checklists.
On your checklist, include items that encourage focus on the reasons as to why the code was developed in the first place – or give a different lens through which to review the code.
3. Prepare your code. Ask yourself “Is this code self-explanatory?” Even if your coding style incorporates comments, the code should be human-readable. The act of reading the code without any explanation forces you, as the reviewer, to ensure the clarity of the code.
If any portion of the code requires explanation to be understood, it might be best to break it down into smaller pieces of code or to add a comment.
4. Affective vs. effective code. Ask yourself about whether or not code changes help achieve goals simply and effectively? A coder may be reluctant to throw out their work and to find a different solution. However, a code change can potentially be more effective than what currently exists. If you are reviewing someone else’s code, bring code change options to the coder’s attention.
5. Don’t neglect dependencies. An often overlooked part of code review is dependencies. It’s easy to overlook a new dependency or a code in a package that it doesn’t belong in. Putting this item on a checklist ensures that the issue is not missed. It can also make the code review faster, as any issues can be resolved ahead of submitting the code for formal review.
For more insights into building an effective code review checklist, see Spectral’s coverage. Lastly, to receive cutting-edge cyber security news, exclusive interviews, expert analyses and security resources, please sign up for the CyberTalk.org newsletter.