There is extensive literature on reviewing code and design documents as a means to check that the software is performing as it should and that the implementation is maintainable and understandable. Some development methodologies, such as Extreme Programming [16], prescribe continuous reviews by peers [40]. In all forms, code reviews are about finding defects in the code, but they are not intended to criticize the programmer.

While the procedural (and psychological) aspects of code reviews are widely described, some practical aspects are not. For example, what should you be looking for in the code? It is not enough to check that the code adheres to the programming standard of the project it belongs to. Such a standard may not exist, be incomplete, or be focused on layout, not on questionable constructs that are a liability (see Appendix B).

What do you want to achieve with code reviews? First, you want to verify that the code is doing its job and that the code is of good enough quality:

1. ■ It is readable by others than the author.

2. ■ It is maintainable – adding new functionality or correcting bugs should not amount to hard labor.

3. ■ It is testable – do you understand what goes in and what comes out?

Secondly, the code should be portable. This means it should be possible to build the program and run it on a different operating system, and also with different compilers and versions of that same compiler. Many compilers offer options to check against the language standard.