This post was originally published in my blog smartpuffin.com.

Code reviews are a great practice to apply in software development. The approach is very simple: when you're done with your code, give it to someone else to look at and leave comments.

Despite of its simplicity, it brings considerable advantages. Here are 7 reasons why this practice is useful.

1. Finding bugs

Another developer, just by looking at your code, may find bugs or forgotten scenarios.

No one writes perfect code all the time. A second pair of eyes is really helpful.

Even quality assurance engineers can miss some obscure cases which can easily be spotted by looking at the code with fresh eyes.

2. Finding problems

You can spot cases when it is not strictly a bug, but something still can be improved. Think questions like this:

• "This is not exactly a bug, but do you think it would be better if we did X instead?"
• "If there are too many elements, this method is going to be slow. How about we sort the items first and use the binary search? How about we use a hashmap, a heap, a graph, a set, a smart algorithm, an index on this field, a garbage collection trick?"
• "Maybe we should normalize these tables and not duplicate this data?" (Or, perhaps, the other way around.)
• "A test is missing for the situation N."
• "When the user does X, the system behaves in way Y. But maybe users would prefer Z?"
• "You implemented something that was missing from the specification, let's figure out what it should be."

Here are some tips about how to improve your thinking about corner cases.

3. Improving code quality

You might be using a static analysis tool, such as StyleCop for C#, Checkstyle for Java, or Lint for CSS. However, the tool cannot catch all problems.

For example, a reviewer can give an advice about a class name, or how to split the logic between methods, or how to separate responsibilities between modules or services.

Overall, the reviewer should be able to read the code easily. After all, we read the code 10 times more often than we write it.

A developer writing the code is so immersed into the context that they understand everything. However, after a couple of months all knowledge is lost, and your own code looks as unfamiliar as if someone else's. So making the code readable is for your own benefit.

And what is the better way than, you know, ask someone to read it?

4. Testing

The reviewer runs your code to see if it's working, and how exactly. By doing that, they may find some bugs. This is great because it helps you to publish a better product, you get the feedback faster, and the load on the QA is reduced.

5. Educating junior developers

It would be a mistake to think that junior developers cannot or shouldn't review the code of more senior ones. They are very much able to find bugs or problems with code readability.

But another important aspect is that they learn how to do things. By giving them your awesome code to review, you teach them on an example.

6. Sharing the knowledge

A team member, while reviewing someone else's code, learns about the part of the system which is being changed. They build a better understanding of the system as a whole.

And next time they have to implement a feature in that area, they are prepared.

7. Building trust

I know this one sounds a bit strange. How am I supposed to trust the colleagues who are going to criticize me?!

But hear me out. Code reviews, when everyone in the team is doing them equally, help the team members to feel like they are being trusted. It builds the sense of reciprocity. If you are asked to review someone's code, you feel like they respect you and your opinion. If you ask someone to review your code, you show that you value their input and are open to feedback and improvement.

You need to make sure to criticize constructively and not attack or condescend. If someone says to you: "that's a horrible code", no trust is going to be built for sure. It is demotivating and simply annoying. You are not going to want to ask that person anymore.

The feedback should be given in a kind and constructive way, and make sure (!) to always (!) explain the reasons. Absolutely do explain why you think it should be done in a different way. You found a bug? You found a problem? You cannot read it easily? Does it not play along with other parts of your system? Explain that.

If you can give a constructive advice about how to do it better, that's the best.

Do you do code reviews? What does the process look like? What advantages do they have for your team? Please share with me, I'd love to know!