Top 10 Tips to Improve Code Reviews

Code review can be likened to eating broccoli.

Many code reviews are superficial and less efficient than they should be.

Are there any ways we can encourage code reviews that are more thorough and lead to better code? I think so.

This article will provide tips for both the code reviewer as well as the code reviewee. These will help you to get more value from code reviews and make it a bit less unpleasant.

Top 10 Tips to Improve Code Reviews

These suggestions, except the first, assume that your code has been reviewed in a pull-request workflow like GitHub flow and trunk-based programming with PRs. Other methods of code review exist, but they are less common so I am not addressing them.

1. Pair Programming

Let’s get the obvious answer out the way.

Pair programming involves two developers working simultaneously on one piece of code. This can be done by sitting at the same keyboard, or perhaps via screen sharing.

The driver is the person who controls the keyboard. They may switch roles with the navigator or observer at regular intervals or on an as-needed basis.

All code can be viewed in real-time by two developers. As the advocates point out, the unique roles of driver, navigator, engage different parts in the brain which allows the pair to be more productive than one developer working alone.

This allows code to be reviewed in detail as soon as it’s written.

Although many teams believe this eliminates the need to have an asynchronous code review later, opinions may differ.

Pair programming may not be possible for all teams or at all times. You should not pair up with someone who works in a different time zone, has different schedules, or is otherwise prohibited by company policies. If you aren’t comfortable with pairing or believe it would be beneficial to do another review, please continue reading.
Also read: 10 Best Paid Online Survey Websites In The World

2. Make small pull requests

Although it may seem counterintuitive, the best way to get code review done is to make your PRs smaller.

It is a well-known fact that humans prefer small, easily digestible bits of data. Splitting large data sets into smaller pieces allows us to consume more data, even if the total amount is not the same. Newspaper columns are short because articles are divided up with illustrations and subheadings.

It follows that, logically and empirically, a series of 10 100-line PRs will receive better reviews than a single 1000 line PR, even though they contain identical changes.

Your PRs should be small and easy to read. If you are a reviewer and see a large PR, ask him to split it into smaller PRs.

3. You can work in small batches

This is related to small pull requests. You don’t want to be tempted by the temptation to write a 1,000-line patch and then divide it into 10 PRs for review. Instead, think about the benefits of working in smaller batches.

• Feedback is more frequent when there are more PRs.
• As an author, it is easier to consider small, focused PRs.
• Small PRs are reviewed more quickly
• Merger conflicts are less common for small PRs

Perhaps the most surprising reason to use smaller PRs is:

• It’s much easier to look at others’ work when everyone is used to working in small batches.

4. Prioritize Code Review Over Writing Code

We tend to review more code when it takes several hours or days for code to be reviewed. This results in larger pull requests. Reviewers are more likely to delay reviewing larger pull requests because they take longer to review. It can take hours or even days for code to be reviewed.

We must take on every step of the process to break this negative feedback loop. As we have already mentioned, smaller, more frequent pull requests are only one part of the solution. Frequent code review is another key component.

This simple rule will break any team from this bad habit: Review code before you write code.

Before you start your day, check to see if any code is still available in your IDE before you go.

Before you start your next task, check if there is any code that needs to be reviewed before you create a PR.

Tribbles attack code reviews, such as Tribbles, can multiply and spread quickly if they’re not exterminated immediately.

This and the other suggestions will quickly show that your entire team operates at a rapid pace of write-review merge, which takes no more than an hour. To speed up the process, peer programming might be a good next step.

5. Use a tool to enforce style

Stop looking at coding style. Seriously. It’s time to stop. It is a huge waste of time and energy. It’s also fraught with unneeded emotions.

A code formatting tool is useful. It can be added to your pre-merge automation. Any code not conforming to the standard should be removed from the PR. It doesn’t matter which style you choose, it is more important than the fact your style is enforced automatically.

I don’t know if you agree, but I prefer a tool to tell me that tabs should be used instead of spaces than a colleague telling. Although I may get mad at the tool, I can still use it at lunch. This time and energy can be used to review the code’s structure and functionality.
Also read: Snapchat Planets: Order & Meaning Explained (Complete Guide!)

6. Linters

Many languages have a lot of linters. Make use of them. You can use many of them. Linters can improve code quality, security and complexity. They also offload some cognitive load from the code editor.

7. Make your code readable

It is subjective to be able to read code. It’s nevertheless very important.

Write your code with your human audience in mind, as a code author.

If you find yourself wondering “WTF?” while code reviewing, please leave a comment to improve. Even though you can figure it yourself, it is a great way for the author learn how to write more readable codes.

This is why juniors should actively participate in the review of seniors’ codes.

8. Do One Thing

Every pull request, every commit should do only one thing. Have you found a bug in a feature that was added? Make the bug fix public in a separate PR.

Is it necessary to reformat an entire file in order to comply with new formatting rules? This should be a separate PR.

It’s not difficult to try and review a bug fix or a new feature.

Make a commitment early. Make sure to commit often. Commits and PRs are completely free.

9. Send PR messages and descriptive commit messages

Code review doesn’t have to be about. A pull request should also include PR and commit messages. It can be frustrating to try and debug something that was done 9 months ago by someone who is no longer employed by the company.
Also read: Top 10 Internet Providers In The World | List Of Fastest ISP Providers

10. Be polite

Never use code reviews as an excuse for your technical skills. Always be polite. Make suggestions for improvement. Be humble. When your suggestion is an opinion and not a deal-breaker, be honest.

A rude reviewer is not something anyone likes and they will try to get rid of them. To get code authors to be more open and make code reviews enjoyable, it is important to create small, easily-reviewed PRs. This is a way to make them friendly and offer them the opportunity for bi-directional learning.