Code review or software inspections are used to spot software errors, omissions and anomalies. The code review as the name implies is to look at the source code for errors and defects. To successful perform a code review a team of at least four people must be formed. The roles are:

1. Author – programmer: the one who owns the code and is responsible for fixing the errors.
2. Inspector: Inspects the code and/or the documentation to find errors – omissions.
3. Reader: Presents the code – documentation
4. Scriber: Writes the findings of the code review meeting.
5. Moderator: Manages the process and facilitates the inspection.

It is very important to keep any questions or comment to the code and not to criticize the developer. When done correctly code review is a positive experience for the team and a learning tool for all levels of developers.

In order to initiate a code review you must:

• Have a complete and precise documentation of the code under inspection.
• The team must know the coding standards that the organization uses.
• The code must be updated and must compile, prior to the inspection. It is a waste of time to inspect code that does not compile.

During one hour of inspection about 120 lines of code are reviewed. It is not recommended for the code inspection to last more than one and a half hours.
It is very important during the inspection to read and translate the code in plain English, based on the specifications. This way everyone can examine the logic and validity of the code.

Why should somebody prefer code reviews from testing?

• During the testing, there is a possibility that an error can mask other errors.
• Testing does not guarantee the code quality and code efficiency.
• In applications that use threading errors cannot be caught with testing but only with a thorough code review.

An advice to software project managers:
I would recommend planning time for code reviews in every project. Code reviews is a great way to mitigate code related risks during the early stages of development.

References and useful links

1. Rober Bogue (2006) Effective Code Reviews Without the pain http://www.developer.com/tech/article.php/3579756/Effective-Code-Reviews-Without-the-Pain
2. Josh Poley(2007) Best Practices: Code Reviews http://msdn.microsoft.com/en-us/library/bb871031.aspx
3. Sommerville I (2006) Software Engineering. Addison Wesley; 8th edition
4. Wikipedia (2010) List of tools for static code analysis http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#.NET_.28C.23.2C_VB.NET_and_all_.NET_compatible_languages.29