Yesterday, I read an article about Code Review Best Practices, so let me tell you some interesting notes about it:

Whenever we perform CRs (Code Reviews) in our projects, we can benefit our team:

• Try to write your code easy to read because code will be periodically reviewed.
• Try to put out the best effort while coding because somebody will eventually review your implementation.
• Whenever possible, reduce bug occurrence; remember: there will be many “eyes” on your code.
• Share knowledge and experience with others coders about issue resolution when the CRs occur.

I prefer do the Code Reviews before we complete the code in order to improve our implementation and then put it in the main branch.

The review does not need much time; that’s why we need to prepare our code. Some recommendations for that are:

• Split the submits. In the first submit, we upload interfaces or “skeletons.” In the second submit, comes the implementation.
• Before we submit the code, it’s necessary to have tested it. It can help to reduce errors in the “builds.” That means that when the functionality was implemented, the code worked and the reviewer suggested some refactoring ideas (if necessary).

The “commit messages” are important: they describe your “commit” with some details. On the internet, there is a lot of information about how you can improve your comments when you submit some code into your code repository like: use the first line as a subject when you submit a lot of changes, and you can list changes with “bullets” using “-” or “*” symbols.

When you are “the reviewer”, you know every change has a purpose, so when the purpose is unclear, that indicates the code needs to be rewritten. You can use the “commit messages” in order to get more ideas about the change. If the commit messages are unclear, the developer has a lot of work ahead.

As a reviewer, if you see duplicate code, you can suggest extracting that functionality in another class or method. Maybe you could use it in other classes. Remember, the functionality that you have been reviewing exists in others libraries, so you can suggest resolving the problem using an existing library.

It is a good idea to have some standards. If you have them, share them with the developers. Some examples are naming conventions, commit messages conventions, or some rules for good reviews.

Style is important, sorry to break it to you. When you read code, you are hoping that the code be clear (have you noticed that all the previous points are related?).

Please, if you are the reviewer, leave positive feedback. The Code Review as an activity does not need to be an opportunity to offend the collaborators. Be polite to the reviewees. Let the reviewees learn and improve some skills. You can contribute to that. Your comments can be friendly and concise. Pay attention to the code, not the author. Ask for clarification when something is unclear.

I’d like to share an anecdote with you. I remember when I was coding some years ago, I received a email from my coworker with some comments and questions about my implementation. That was an explanation, my work was not completed. My coworker started the Code Review assuming the work was done. Communication failed. I suggest you establish the correct moment to start the CR.