What makes a great code review?

Code reviews: you either love them, or you hate them! If you fall into the former category, it may be because you’ve been on the receiving end of some pretty poor mandatory code reviews, or had the whole process add unpredictably long latencies to your workflow.

This is a shame, because a great code review culture can be a massive boon to both a business and the final product. In this guide, we cover how you can be a better code reviewer, and share a number of resources every developer should have in their bookmark bar.

For those of you who want a more comprehensive delve into the topic of code reviews — or simply like watching videos — check out our course on Code Reviews: Best Practices. On top of the fundamental process, it covers how to automate static code analysis, create effective pull requests, and manage difficult code review situations.

What is a code review?

A code review is when someone other than a code’s author manually views and checks the source code. This can be performed by multiple people — or be performed multiple times by the same person — for a more thorough analysis. Parts of this process can also be automated.

Reviewers look at several factors when studying the code including design, style, functionality, complexity, naming, and testing. These reviews may be conducted in-person or asynchronously. 

What is the purpose of a code review?

The most obvious benefit is making sure bad code doesn’t make it into production. But there are actually a lot of other benefits, such as knowledge sharing, improving security, and building a sense of teamwork and collaboration. It also helps aid organizations in achieving greater standardization. 

Ensuring quality code (You miss more than you think)

By the time you’ve finished programming, you’ve been staring at the same lines of code forever: let’s face it, you’re probably sick of it, and never want to see it again. At this point, it’s hard to be objective, and the mistakes in your own code are missed as your eyes sweep over them, only seeing your intent and not what’s actually there.

That’s when a pair of fresh eyes really helps. It gives you the peace of mind that someone else will help spot any bugs or other lapses in the source code, while you go make a much needed coffee (or tea). Also, instead of having to patch bugs after the code has been released, bugs can be addressed early on in the software development lifecycle. 

Knowledge sharing and teamwork (Also underrated)

While it may be tempting to never want to show anyone your code out of a sense of embarrassment, a code review helps both the reviewer and the reviewee learn.

• The person who reviews the code gets to study the source code and style.

• The code’s authors can learn from the feedback shared and have the chance to put it into practice immediately.

• Both parties benefit from improved communication and understanding on what is going on, breaking down silos.

Through this process, code authors and reviewers can brainstorm ideas, discuss objectives, and develop workflows. 

Security (Not just the feeling of being secure from a code check)

Secure code reviews can be used to identify vulnerabilities and security flaws in a manual or automated process. This process helps to avoid late-stage defects and improve the code’s quality as well as maintainability. Avoiding technical debt is another benefit of code reviews. 

What Is the Difference Between a Code Review and a Code Checker?

Code checkers use software to analyze source code. Some organizations use code checkers during development to speed up the review process and reduce the potential for human error. This software uses static analysis to review the source code for bugs, logic errors, style, documentation, and syntax. 

What Should a Good Code Review Look Like?

That’s all good and well, you might say, but how do I actually go about doing a code review, and make sure I do it properly?  Before reviewing the author’s code, make sure you’ve identified the purpose of the session, and be sure to follow these best practices.

Create a Checklist for Review

There are several areas you may look at during a code review, including design, security, maintainability, logic, and quality. To help maintain focus, create a checklist on the front end before beginning your review. 

• Do I understand what the code is supposed to do?

• Does the code do what it’s supposed to do?

• Can this source code be simplified? Are there any redundancies?

• Are the names easy to understand and descriptive?

• Do the names follow our conventions?

• Can I quickly discern the role of functions, classes, and methods?

• Does the source code use encapsulation and modularization?

• Is it reliant on old functionality or code?

• Does it introduce vulnerabilities? How could I potentially exploit this code?

• Does the code require any documentation?

• Does it meet coding and style standards?

As you conduct more reviews, you may want to add more items to your checklist to capture the knowledge you’ve gained. 

Include Benchmarks and Metrics

It can be helpful for software development teams to select metrics or benchmarks prior to the code review. This information can be tracked over time to study the effectiveness of reviews and their impact on code quality. Metrics also give teams objective measures to structure code reviews around. The following three metrics are good starting points to include in your review process:

Review session length: The length of each code review session will vary based on the reviewer and source code. Track the amount of time spent per session to get a feel for the average amount of time spent across your team. Especially long sessions may mean readability issues are at play. Shorter-than-average sessions may mean the reviewer needs a bit more focus (or they’re just reviewing really high quality code!). 

Defect density: To calculate the defect density, divide the number of defects by thousands of lines of code. This metric is used to measure code quality and can help you allocate resources to projects that need more support. 

Reaction time: This metric is useful to drive collaboration on projects with multiple developers. Simply chart how long it takes a reviewer to respond to a comment addressed to them. Shorter reaction times generally mean a more collaborative, responsive team. 

You can also use GitPrime’s Code Review and Collaboration suite of features for greater visibility into the end-to-end pull request process workflow.

Stick to 200-400 Lines of Code

For best results, review no more than 400 lines of code at a time. Any more than that and you risk missing bugs, logic flaws, and other defects. Better yet, if you can limit yourself to 200 lines of code at a time, you’ll have greater success. 

Explain Your Feedback

While it’s helpful to identify problems within the source code, it’s more beneficial to explain why specifically they’re a problem. You want to be constructive and instructive with your feedback. Ask questions and justify your feedback. If you approach issues with the intent to understand the author’s thought process, you’ll help them work through a solution and avoid putting them on the defensive. 

Try giving feedback in person whenever possible. This helps to prevent miscommunication and drives greater discussion around potential solutions. You may want to present scenarios to explain your reasoning for proposed changes. Managers can participate in and observe code reviews to encourage healthy communication and collaboration.

How Can I be a Better Code Reviewer?

Enhancing your techniques for code reviews can improve the quality of the code you’re reviewing as well as your own code. For better code reviews, show humility and focus on the code (rather than the author). 

Be Humble

Code reviews don’t need to be a hierarchical process. In other words, senior developers shouldn’t be the only ones reviewing code. Entry-level developers can provide a fresh perspective and should be integrated into the process from the start. To improve your code reviews, take the attitude that you can learn something new from everyone on your team. 

Critique the Code

Critiquing code is a bit of an art. You want to identify issues without making it sound like the author is the issue. The focus here should be on the code itself. Read: not the code writer. Avoid “you” and “should” statements. Don’t just highlight how you would do things. Instead, go back to your checklist and prioritize standards as well as best practices. Be sure to note what’s working with the code and don’t be afraid to conduct a review session that results in no changes. 

7 Code Review Resources Every Developer Should Have

Code reviews provide opportunities to practice your continuous improvement skills. As you work to refine your technique over time, add these seven resources to your arsenal for best results. 

1. Code Review Best Practices

2. Managing Code Reviews with Azure DevOps

3. Manage Pull Requests at Scale with Code Review

4. The Engineering Manager’s Guide to Code Reviews

5. Gitlab Code Review Guidelines

6. Google’s Code Review Guidelines

7. Stack Overflow’s How to Make Good Code Reviews Better

What should a code review include?

What are the 7 steps to review code?

What are the 3 most important qualities of written code?