Hey! I work at Joom on the infrastructure team. In my practice as a code reviewer, I regularly encounter the fact that the author does not understand that the reviewer is not a magic black box into which you can throw any changes and get feedback on them. The reviewer, like the author, as a human being, has a number of weaknesses. And the author should (if, of course, he is interested in a quality review), help the reviewer as much as possible.

I want to tell you how the author of the code can simplify the work of the reviewer and thereby increase both the quality of the review and the productivity of the reviewer. This article may well be used in your internal corporate documentation as a guide for preparing changes for review. It, in fact, was compiled from such a guide.

Why do we do a code review

You probably know this without me. Therefore, I will tell you about the very basics, without going into details.

Static code analysis is the process of detecting errors and defects in software's source code.

Static analysis can be viewed as an automated code review process. Let's speak on the code review now.

Code review is one of the oldest and safest methods of defect detection. It deals with joint attentive reading of the source code and giving recommendations on how to improve it. This process reveals errors or code fragments that can become errors in future. It is also considered that the code's author should not give explanations on how a certain program part works. The program's execution algorithm should be clear directly from the program text and comments. If it is not so, the code needs improving.

The id Software company possesses a PVS-Studio license. However, we decided to test the source codes of Doom 3 that have been recently laid out on the Internet. The result is the following: we managed to find just few errors, but still they are there. I think it can be explained by the following fact.