9 Best Practices for Code Review
Code reviews are important. They improve code quality. They make your codebase more stable. And they help programmers build relationships and work together more effectively.
But reviewing a peer’s code is easier said than done. And running a review process can be a nightmare for team leads.
9 Best Practices for Code Review
If you want to improve the efficiency and effectiveness of your review process, start here. Get our best practices for participating in and running reviews.
For Participating in Peer Code Reviews
We’ll let you in on the best-kept secrets of peer reviews. Peer reviews are all about collaboration, not competition.
Follow these five best practices to effectively review code.
1. Know What to Look for in Code Reviews
It’s important to go into reviews knowing what to look for. Look for key things, such as…
Structure. Style. Logic. Performance. Test coverage. Design. Readability (and maintainability). Functionality.
You can do automated checks (e.g., ) for some of the things — e.g., structure and logic. But others — e.g., design and functionality — require a human reviewer to evaluate.
Reviewing code with certain questions in mind can help you focus on the right things. For instance, you might evaluate code to answer:
- Do I understand what the code does?
- Does the code function as I expect it to?
- Does this code fulfill regulatory requirements?
By evaluating code critically — with questions in mind — you’ll make sure you check for the right things. And you’ll reduce time when it comes to testing.
2. Build and Test — Before Code Reviews
In today’s era of Continuous Integration (CI), it’s key to build and test before doing a manual review. Ideally, after tests have passed, you’ll conduct a review and deploy it to the dev codeline.
This ensures stability. And doing first will cut down on errors and save time in the review process.
Automation keeps you from wasting time in reviews.
Need a better automated check? Check your code in Helix QAC >>
3. Don’t Review Code For Longer Than 60 Minutes
Never review for longer than 60 minutes at a time. Performance and attention-to-detail tend to drop off after that point. It’s best to conduct reviews often (and in short sessions).
Taking a break will give your brain a chance to reset. So, you can review again with fresh eyes.
Giving yourself time to do short, frequent reviews will help you improve the quality of the codebase.
4. Check No More Than 400 Lines at a Time
If you try to review too many lines of code at once, you’re less likely to find defects. Try to keep each review session to 400 lines or less. Setting a line-of-code (LOC) limit is important for the same reasons as setting a time limit. It ensures you are at your best when reviewing the code.
Focusing on fewer than 400 lines makes your reviews more effective. And it helps you ensure higher quality in the codebase.
5. Give Feedback That Helps (Not Hurts)
Try to be constructive in your feedback, rather than critical. You can do this by asking questions, rather than making statements. And remember to give praise alongside your constructive feedback.
Giving feedback in-person (or even doing your review in-person) will help you communicate with the right tone.
Your code will always need to be reviewed. And you’ll always need to review your coworkers’ code. When you approach reviews as a learning process, everyone wins.
How effective are your reviews? Compare your skills to your peers. Check out the developer challenge >>
For Running Code Reviews
Running reviews — and making sure everything has been properly reviewed — can be a huge challenge.
Follow these four best practices for effective reviews.
6. Communicate Goals and Expectations
You should be clear on what the goals of the review are, as well as the expectations of reviewers. Giving your reviewers a checklist will ensure that the reviews are consistent. Programmers will evaluate each other’s code with the same criteria in mind.
By communicating goals and expectations, everyone saves time. Reviewers will know what to look for — and they’ll be able to use their time wisely in the review process.
7. Include Everyone in the Code Review Process
No matter how senior the programmer is, everyone needs to review and be reviewed. After all, everyone performs better when they know someone else will be looking at their work.
When you’re running reviews, it’s best to include both another engineer and the software architect. They’ll spot different issues in the code, in relation to both the broader codebase and the overall design of the product.
Including everyone in the review process improves collaboration and relationships between programmers.
Make your reviews more effective. Run them in Helix Swarm >>
8. Foster a Positive Culture
Fostering a positive culture around reviews is important, as they play a vital role in product quality. It doesn’t matter who introduced the error. What matters is the bug was caught before it went into the product. And that should be celebrated.
By fostering a positive culture, you’ll help your team appreciate (rather than dread) reviews.
9. Automate to Save Time
There are some things that reviewers will need to check in manual reviews. But there are some things that can be checked automatically using the right tools.
, for instance, find potential issues in code by checking it against coding rules. Running static analyzers over the code minimizes the number of issues that reach the peer review phase. Using tools for can help, too.
By using automated tools, you can save time in peer review process. This frees up reviewers to focus on the issues that tools can’t find — like usability.
How to Do Code Reviews Effectively
If you want to do reviews effectively, you’ll need the best tools.
Using Perforce Tools for Better Code Reviews
Perforce has tools to improve your review process from beginning to end.
How Helix QAC Improves Code Reviews Before They Start
Helix QAC is a . You can use it to analyze code and eliminate coding errors before the code gets to the peer review phase.
Helix QAC makes sure your code complies with coding rules. And it highlights and prioritizes issues that need to be fixed, so programmers can be more efficient in the review process.
Reviewers can add their annotations into the source code — alongside Helix QAC’s diagnostic messages. And programmers receive notifications when Helix QAC finds issues that relate to their portion of the code.
How Helix Swarm Makes Collaboration Easy
Helix Swarm is a web-based that is included with Helix Core. You can use it to scale reviews as your team grows and improve collaboration during the process.
Helix Swarm makes it easy to run reviews by automating the process. Teams can use this tool to monitor progress and see which ones are complete — and which are still in progress.
Reviewers get automatic notifications about their tasks and a dashboard of their action items. Plus, everyone can easily collaborate by having conversations directly in the code.
Using Git? You can use and for Git code reviews, too.
Make Your Code Reviews Better
Helix QAC and Helix Swarm and other build runners. So, you can run builds and tests prior to your peer review cycles.