A code review is a process where someone other than the author of a piece of code reviews that code. The main purpose of code review is to make sure that the solution fixes the problem in the best possible way from a code and product perspective. In this article, I’ll walk you through the best practices for performing a code review.
What is Code Review?
Code review is a code quality assurance activity in which one or more people on a team verify a program primarily by viewing and reading portions of its source code, and they do so after implementation or as an interruption of the implementation. At least one of the people must not be the author of the code.
Also, Read – Machine Learning Full Course for free.
While doing a code review, a code reviewer has to look at:
- Design: Is the code well designed and appropriate for your system?
- Functionality: Does the code behave as the author probably intended? Is the way the code behaves well for its users?
- Complexity: Could the code be simplified? Could another coder easily understand and use this code when they encounter it in the future?
- Testing: Does the code have correct and well-designed automated tests?
- Naming: Has the coder chosen clear names for variables, classes, methods, etc.?
- Comments: Are the comments clear and useful?
- Style: Does the code follow our style guides?
- Documentation: Has the coder also updated the relevant documentation?
How To Do A Code Review?
Below are some of the important steps a code reviewer need to consider while doing a code review.
Always Remember That There is no Perfect Coder:
Before you start examining code, you should understand that there is no perfect code, only a balanced code. As a reviewer, you need to strike a balance between the need to make progress and understanding the importance of change.
Stop striving for perfection. You’re not just writing code for the code, you’re solving a business problem with the code. If the code fixes a problem and improves the maintainability, readability, and understandability of the system, even if it’s not perfect, don’t delay it for several weeks. Leave a comment on how the moderator can improve their code and give them the go-ahead.
Rely on Technical Facts:
We all have different backgrounds and experiences, but we need to turn them off while reviewing the code. When deciding whether the solution you are reviewing is well written or not, you should rely on the facts and technical standards, not your personal preferences.
For example, when coding, you might still use a semicolon at the end of the line, but the author of the code you’re reviewing does not. The first thing to do is to leave a comment like “Add a semicolon here”. But what you should do instead is create a style guide and make it a standard on the team.
The codebase should be consistent and unwritten to conform to personal preferences.
Consider Discussion and Not Conflicts:
I have seen many examples where the reviewer got it wrong about “how to write code”, left a comment about it while reviewing the code, and after realizing he was wrong, he still decided to bend her line just so they didn’t sound silly or like they didn’t know anything.
Code review is not a ring where you have to dominate your opponent. You are a team. You are working towards a common goal. Everyone is your teammate. The first thing to do in conflict is to reach consensus.
This is best done in a chat or video call, not in the comments on GitHub. It’s a lot faster. So don’t sit on a conflict for days, try to resolve it as quickly as possible.
Your Comments Must Look Positive:
First of all, refrain from what you think of the person whose code you are reviewing. Always comment on the code, not on a person. If you see that the author has written “bad” code and it somehow triggers anger, calm down first, then comes back and leave your comments with a calm mind.
Also, never write comments like ādo this and not thisā. Always explain why the author needs to make changes and add a source (link to blog post, documentation, guidelines) where the person could learn more.
But don’t write a complete solution to the problem when explaining why. Code review doesn’t have to take you all day. And it’s not your job to correct another developer’s changes. Find a balance between reporting the problem and providing a straightforward solution.
I hope you liked this article on what is a code review and how to do a code review. Feel free to ask your valuable questions in the comments section below.
