PR review best practices

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, and what are the nine best practices for code review.

Read along or jump ahead to the section that most interests you:

• What Is a Code Review?
• Best Practices for Code Review
• Peer Code Review Best Practices
• How to Run a Code Review
• Apply Code Review Best Practices With the Right Tools

➡️ see how Static Analysis can improve code reviews

What 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.

9 Code Review Best Practices

Here 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

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.

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.

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 >>>

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.

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.

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: Are Your Code Reviews Effective?

How to Run a Code Review

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.

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.

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 >>>

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.

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

Apply 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 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.

▶️ Watch a Helix Swarm Demo

Enforce Code Review Best Practices 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.

➡️ static code analysis free trial 

Related Resources

• How to Increase Developer Productivity

How can I improve my PR reviews?

What are some best practices for peer review?

What are the top 3 most common types of comments feedback you have given on pull requests?