A guide to conducting effective code reviews
Code reviews get a bad rap. They’re labelled as a waste of time, or an opportunity for senior developers to call out and ‘pick on’ newer team members. But code reviews themselves aren’t bad; it’s when they’re done badly that they become a problem.
Done right, a code review promotes greater quality software, stronger teamwork, and more inspiration for creativity. Instead of being a forced peer review that creates hostility amongst your team, good code reviews enable team members to share knowledge. So, how do you keep code reviews effective?
What a code review is, and what it isn’t
A code review is a scheduled opportunity for two or more developers to inspect and discuss a piece of code, of no more than 400 lines maximum when done optimally. Code reviews are not, however, part of your daily stand up meeting. They aren’t an opportunity to exert superiority over a colleague or show off, and they aren’t a platform for coding style wars.
Instead, code reviews focus on the objective quality of the code. They help ensure that developers meet set coding standards and best practices. This is usually evaluated by asking things like ‘does it work’, ‘is it easy to understand’, and ‘does it conform to your company’s coding conventions?’
Code reviews also seek to find and fix as many errors, vulnerabilities and inconsistencies as possible. That means that developers conducting a code review will look for any redundant code, anywhere the code is incomplete, and so on. A big part of effective code reviews is the use of a checklist to compare the code against. This keeps the review evaluations reasonable and directed to the code alone – everybody’s code is held to a clear set of standards.
Why are good code reviews important?
Effective code reviews are the foundation of better quality software. They offer a receptive, open environment, which hosts a great opportunity to ask questions, suggest changes and fixes, and share expertise.
Code reviews also mean that developers are exposed to a variety of different ways of thinking around problems. Programming is a creative process, and another developer might have a completely different approach to coding certain features. Effective code reviews will bring this variety to light, offering opportunities for innovation and creativity.
Poor code reviews, however, have the opposite effect. When mishandled, they can cause higher stress in developers, damage the team atmosphere, and waste everybody’s time for no gain. An effective code review is not to be used as a rubric for an employee review. When the basis of compensation, reward or promotion is based on code reviews, focus will shift from writing good code as a team to improving personal metrics in comparison to others, with little to no care for the quality of code. So, keeo employee reviews separate from code reviews.
Everybody, every line
First, a code review should be for every line of code your team writes – whether it’s an integral function, or an extra feature. Ensuring that every part of your code goes through a review promotes code consistency across your product, meaning higher quality software.
Just as every line of code should go through review, every developer on the project should be completing code reviews. Yes, the more experienced may spot more issues, but that will help newer team members improve, and their inclusion in the review process keeps the playing field level.
Plus, when everyone is subject to a code review, it promotes teamwork across experience levels. This prevents an ‘us vs them’ divide and feelings of inadequacy – two things that can damage employee morale.
Short and sweet
Effective code reviews are little and often. So, break code down into small, manageable chunks. Below 200 lines of code is great. Between 200 and 400 is manageable. Just be sure not to go above 400 lines of code, as this is the point where reviews become less thorough.
Completing these smaller code reviews often, meanwhile, means that problems can be nipped in the bud. Rather than being forced to work on code they can’t remember a lot later down the line, colleagues can get to work implementing any fixes ASAP. The code is still fresh in their minds, and implementing fixes or edits will be easier and faster.
When ensuring that code reviews remain focused and effective, it can be helpful to automate any code edits that can be automated. Things like syntax changes can come down to personal preference. When a code review results in a mess of syntax edits, it’s demoralising. It wastes the time of the developer changing the code, and the more important fixes can end up buried, missed entirely or ignored. By automating such edits, the review process is not only kept short and sweet, but also focused on the meat of the code, the important bits that need human attention to amend.
Attitudes for effective code reviews
It’s important to keep code reviews positive. When they verge towards the derogatory or the petty, developers will quickly become hostile to the process. They’ll dismiss any comments in the review as vindictive or overly nit-picky.
Code reviews also need to remain objective rather than subjective. It’s common for developers to find issues with a team member’s code due to subjective preferences. So, keep criticism constructive. That means being able to answer why a section needs fixing or re-writing, and, if asked, how to do so.
People will have different opinions, and it’s okay to disagree with your colleagues – as long as you discuss the matter, and agree upon a final solution. Code reviews aren’t about creating a hive mind, but rather questioning and finding ways to improve the code behind your product.
Don’t take it personally
Developers are passionate about their code, and it can be hard to hear when your code needs tweaking or fixing. Code reviews, for this reason, can be difficult. Having every piece of code you write critiqued by peers is nerve-wracking.
Remember that a code review is not a personal attack on a developer’s coding skills. If it’s your code under review, be open to suggestions and discussions. Similarly, if you are reviewing a colleague’s code, don’t make the code review into a personal attack. Focus should be on the quality of the code, not the programmer that wrote it.
A good practice is to avoid the use of the second person, so instead of referring to the developer with ‘you/your’ refer to ‘the’ code. For example, ‘You need to rename this method/ could you rename this method’ should be ‘this method needs to be renamed’. It’s easy, and it helps the review seem less personal. After all, it doesn’t matter who fixes the code. Just make sure it gets fixed.
Get the most out of code reviews
Many people view code reviews as a great evil. Done wrong, they are. Bad code reviews are pointless and can even be damaging to both the final product, and team morale.
But, by keeping code reviews short and sweet, focused on the code, and adhering to a checklist, code quality rockets. More importantly, you nurture and cultivate teamwork. There’s a lot to gain from conducting effective code reviews.