Code review is all about making code better. However, reviewing a peer’s code is easier said than done. Not to mention that running a review process can be a nightmare for team leads. For that reason, we explain what to look for in a code review, the code review process, best kept secrets of peer code review, and what are the nine code review best practices.
Read along or jump ahead to the section that most interests you:
Table of Contents
➡️ Improve Code Reviews with Static Analysis
Back to topWhat Is a Code Review?
A code review — also known as a peer code review — involves one or more team members checking another teammate's work. This involves viewing changes made to the source code before they are implemented into the codebase.
Why Review Each Other's Code?
Code reviews are important because they improve code quality and make your codebase more stable. In addition, they help programmers build relationships and work together more effectively.
Back to top9 Code Review Best Practices: Best Kept Secrets of Peer Code Review
Back to topHere are nine best practices for code review:
1. Know What to Look for in a Code Review
2. Build and Test — Before Review
3. Don't Review Code for Longer Than 60 Minutes
4. Check No More Than 400 Lines at a Time
5. Give Feedback That Helps (Not Hurts)
6. Communicate Goals and Expectations
7. Include Everyone in the Code Review Process
8. Foster a Positive Culture
9. Automate to Save Time
📕 Related Content: How to Do Code Reviews
What to Look for in a Code Review Process: Peer Best Practices for Code Review
We’ll let you in on the best-kept secrets of peer reviews. Peer reviews are all about collaboration, not competition.
Follow these five peer code review best practices.
Peer Code Review Tip #1. What to Look for in a Code Review
It’s important to go into reviews knowing what to look for in a code review. Look for key things, such as…
Structure. Style. Logic. Performance. Test coverage. Design. Readability (and maintainability). Functionality.
You can do automated checks (e.g., static analysis) 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.
Peer Code Review Tip #2. Build and Test — Before Code Review
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 automated checks first will cut down on errors and save time in the review process.
Automation keeps you from wasting time in reviews.
➡️ Start Your Free Static Code Analysis Trial >>>
Peer Code Review Best Practices Tip #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 code reviews often (and in short sessions).
Taking a break will give your brain a chance to reset. So, you can review it again with fresh eyes.
Giving yourself time to do short, frequent reviews will help you improve the quality of the codebase.
Peer Code Review Tip #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 code 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.
Peer Code Review Best Practices Tip #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.
📕 Related Resource: Developer Challenge: How Effective Are Your Code Reviews?
Back to topBest Kept Secrets of Peer Code Review: How to Run a Code Review Process
Running a code review — and making sure everything has been properly reviewed — can be a huge challenge.
Follow these four best practices for how to run a code review.
How to Run a Code Review Tip #1. 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.
How to Run a Code Review Tip #2. 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.
➡️ Start Your Free Helix Swarm Trial >>>
How to Run a Code Review Tip #3. 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.
How to Run a Code Review Tip #4. 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.
Static code analyzers, 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 lightweight reviews 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.
📕 Related Content: How to Do Code Reviews
Back to topApply Code Review Best Practices With the Right Tools
If you want to enforce best practices for code review, you’ll need the best tools.
A Better Code Review Starts with Perforce Tools
Perforce has tools to improve your review process from beginning to end.
How Perforce Static Analyzers Improve Code Reviews and Code Review Best Practices From the Start
Perforce Static Analyzers — Helix QAC for C/C++ and Klocwork for C, C++, C#, and Java — can be used to analyze code and eliminate coding errors before the code gets to the peer review phase.
Both make 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 with Perforce Static Analyzers' diagnostic messages. And programmers receive notifications when the Static Analyzers find issues that relate to their portion of the code.
How Helix Swarm Makes Collaboration Easy
Helix Swarm is a web-based code review tool 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. See for yourself how Helix Swarm will help you.
Enforce Best Practices for Code Review With Static Analysis
Perforce static code analyzers — Helix QAC and Klocwork — and Helix Swarm integrate with Jenkins and other build runners. So, you can run builds and tests prior to your peer review cycles.
Using Perforce code review tools eliminates waiting time and helps you collaborate better throughout the process. See for yourself how Perforce static analyzers will help you.
➡️ Start Your static analysis free trial
Related Resources
- Learn about using tools to find code vulnerabilities, ensure standards compliance, and reduce time-to-market early in the development process with Perforce's Shift Left 101
- How to Increase Developer Productivity