Code Review: two heads are better than one

Working with code the end game is always to deliver the best quality product free of defects and malfunctions. That is what’s expected of us. But the code is being written by human beings and the part of human factor is not only to be creative and full of amazing ideas no machine can come up with, but also to be prone to making mistakes. How to deal with that? The answer is to involve more of this factor. Sounds funny, but that’s what the term says — two heads are better than one, and therefore the code review is considered to be a good way to get rid of or fix the mistakes that have been overlooked and improve the code quality in the process.

What the code review is

Code review is what you can do to improve your code. How? By letting some other smart guys to look at it. When a developer is done working on a particular code, an issue or a feature, or even submits a pull request for an open source project, another fellow developer goes over it checking for mistakes. This way a fresh perspective can be added. The person reviewing the code considers whether all the requirements are fully implemented, whether there are obvious logic errors, whether there are any inconsistencies or potential problems, and so on.

Of course, the code review has to interoperate with the existing process. It’s more effective to initiate it before the code merged upstream but after it has been written and passed the automated tests. This way the person reviewing the code can spend time by looking for problems that machines have missed.

What is the point of a code review

Understandable, that the main reason for code reviews is finding the defects and opportunities for improvement. To find weaknesses and ensure that the design and implementation is consistent across the application the deliverable code with a test code and the data can be examined. It’s much better to find issues that will need to be reworked early on.

With code reviews the knowledge is being shared across the team and the code base. Thus the developers are becoming more subjected to new ideas and new technologies that they can use when writing a code. So, the element of education is involved. When a junior programmer reviews a code that has been written by a senior programmer he can pick up a few tricks that the last got with experience and has been using automatically. Also in the spirit of mentoring when a senior programmer reviews a code of a junior one, he can iron out some issues before they translate into technical debt. Among the team everyone have to see the modification associated with a defect fix or enhancement. This way everyone will understand the rest of the software. It’s very useful if programmers go a long time not looking at certain modules because of working on complex systems or the components that need to be integrated.

Also by reviewing each other’s code the developers become familiar with all areas of the system which reduces the bus factor in a project. They become more efficient in maintaining the parts of the system that they didn’t write.

What points should be considered when making a code review

To make code review an effective process you might want to keep in mind a few tips:

• Concentrate on logic statements first (this will help to focus your review)
• Attend to comments (this goes for both the reviewer and for the person who asks for a review; as we point out in our previous article, comments might be a useful tool for the other developer to understand what the code does or suppose to do)
• Review no more than 200–400 lines of code at a time (only so much information can be processed by the brain; reviewing more at one sitting might just lower the ability to see inconsistencies)
• Don’t rush to finish (review at a slower pace for a limited amount of time — less than 500 lines of code per hour and take a break after each hour)
• Review things that the tools missed (there’re a lot of code review tools that can find the style and formatting issues; concentrate on other important things that can’t be as easily found)
• Keep it short (the feedback should be small and changes narrow and manageable)
• Do the review as soon as you see the request (it’s not always easy, but the person for whom you are reviewing will be grateful and you’ll grow as a reviewer)
• Use a checklist (to make sure that what’s important is being covered, especially the common mistakes)
• Be positive (you don’t have to become a nasty now-it-all while reviewing somebody’s code; keep it cool and dial down the rude criticism; be constructive and maintain a non-threatening environment)
• If it’s OK, it’s OK (no need to find a problem when there isn’t one)

Wrapping up

So, as you can see, the code reviews aren’t just for finding bugs. For the most of it the tests deal with those. As well as automated tools providing code analysis deal with style and formatting issues. What the code reviews are really about are those things that no tool can check for. This way you can also make sure that the code is readable and sufficiently documented.

In CheckiO you can not only share you code, but also gain the objective points of views of other users. Here many practice making code reviews and are ready to do the best they can on providing you with the additional set of eyes and program oriented brains. Here are some examples of our members’ reviews where you can make sure for yourself: Open Labyrinth, The square chest, Restricted sum.

And how are you involved in code reviews? Do you have any tips or recommendations you follow while reviewing a code?