We have selected a few tips that will help you walk the path to success in code review. Do not miss the chance to become an expert in this matter.

Why do developers spend so much time reading code made by others (code review) instead of reading their own code, even spending that time writing code for another project? Is it worth it?

Let’s face it, while it is much more fun and challenging to write code than to read it, the truth is that this is one of the best practices for achieving a quality result.

If we start from this fact, the answer to the question would be that reading another’s code is not only worth it, but it is also very necessary.

Peer code review is one of the best tools we have to improve as programmers. As I once read on a blog, “You are never going to become a master of your craft if you do not absorb the knowledge of the masters that came before you.”

Thanks to this technique, we not only have the opportunity to detect possible failures in the implementation but also to learn new ways to solve problems.

Doing code review does not mean auditing another’s work with the aim of always finding mistakes. Code review means determining what is being done well in order to keep on doing it and defining what can be improved.

We can summarize what we can achieve by using this code review technique in 3 points:

1. Encourage continuous improvement
2. Improve communication between team members
3. Early detection of coding problems.

Now, what can we take into account when it comes to becoming a code review Master? These are some aspects we can bear in mind when doing a code review:

• Duplicated Code: The most important thing is to refactor when necessary following the three strikes rule.
• Continuous refactoring: Follow the Boy Scout rule, that is, leave the world better than we found it. In this case, it is about going a step further and always leaving the code a little better.
• Error handling: The way in which errors are handled should be taken into account, and the correct use of exceptions should be controlled.
• Potential errors: Try to find situations that the developer has not taken into account, such as what can happen at the ends of the loops, possible unhandled errors, etc.
• Efficiency: Check how efficient the code that is being reviewed is.
• Name of methods: Remember that the function names must specify what they do and not how they do it.
• Name of the variables: Representative names of the variables should be used to ease the subsequent reading.
• Methods length: If there is an extensive method (more than 50 lines), refactoring it would probably be the best option.
• Commented code: It is recommended that the code itself is self-documented, which means that a comment is not necessary to explain what a particular function does. When we need to add comments, it is often a sign that a code refactoring is needed.

• Legibility: The code should be easy to understand. If at the time of its revision we have to take many pauses to interpret it, it is an indicator that it is not clear.
• Tests coverage: Every new functionality must be covered by a test to check that it is working properly.
• No warnings / console logs: It must not have warnings in the compilation, nor must it
  write messages in the console. In case of needing to write a message, it must be done with a logging tool.
• Coding standards: Each project defines its coding standards at the beginning. In each revision, we must make sure that the added code follows those standards.

Finally, it is recommended to use a tool such as Crucible to facilitate the code review. However, before uploading code, it is advisable for the developer to make his own code review verifying the points mentioned above.

In addition to this, it is very important to understand the code we are reviewing so that we can be objective when we do the review. Therefore, it is advisable to talk to the person who developed the code to explain its functionality, why it was implemented, and give a theoretical foundation on the work done. Bearing this in mind, we will have a solid basis on which to conduct the code review.

To Sum Up

At first, it may seem like we are spending too much time on reviewing the code made by a third party, but actually, in practice, there are many more advantages offered by code review: We improve communication within the team, transmit knowledge, increase the quality of the code produced, and the entire team takes responsibility for the development.

So, now you know all this, are you ready to become a Master in code review?

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.