A code review is a process where one programmer's code is analyzed by another programmer. This exercise is useful in ensuring coding standards and best practices are being enforced. This is a phase of a programmer's experience where peer mentoring can come into play, as developers are encouraged to share thoughts on how the code was written and learn from it. The code review should not be treated as a "code ripping" exercise, but as an opportunity to learn from others and improve the general product.
Typically the code review process is handled one on one by a senior software developer, or sometimes in a group environment. A programmer may be asked to "walk through" their code and explain what they did, and (if necessary) why they did it.
 What to Review
Code reviews can include:
- Is the software acting as expected? Does it cover every use case and pass every test? Were any edge cases missed?
- Can any code be optimized for better performance? Could better algorithms be chosen?
- Coding standards
- Are the project's and organization's standards being followed? For example, an organization may require a specific date format in code, or a particular style of code comments be used.
- Are best practices, such as modularization, also being followed?
- Is a set of code showing more bugs on average than the rest of the project?
- While bugs should all be found during testing, a code review can uncover unexpected consequences missed during testing.
- Are there code comments for anything that's not self-explanatory?
- If an API or library is being written, is it documented enough for a 3rd party to understand and use it?
Code reviews are also often an appropriate time to bring up related topics such as teamwork, specifications, and time management. These can directly and indirectly affect the quality of code produced by a team.
When performing a code review of another programmer's work, be sure to
- Show examples. Take a piece of code that could be written better and refactor it in front of the other programmer. Explain what is being changed and why each step of the way. Also demonstrate other similar examples from other sets of code.
- Have the programmer explain their intentions. Understanding what a programmer is thinking is a big part of understanding their code. This can sometimes be conveyed (and often should be) directly in code comments.
- Provide constructive criticism, avoiding berating. Also be aware that while a group review might save time, one-on-one reviews might save a programmer embarrassment in front of his or her peers.
- Consider each programmer's skill level. Not everyone is ready to build large, complex solutions. Discuss if the level of work asked of the programmer has been appropriate, and consider adjusting as needed to help him or her grow their skills.
- Discuss project and organizational goals. Be sure the programmer's work has kept in line with each project's overall goals and targets.
In some organizations it's appropriate for a senior developer to get automated notifications for committed code and review each. Others might take them all in batches and review them on a schedule. Another common scheduling solution is to do them on a regular basis using various samplings of a programmer's complete work.
 Conclusion and Further Reading
Regular code reviews are an important step in improving project outcomes, simplifying software maintenance by enhancing code quality, and progressing a programmer's career.
- Wiegers, Karl (November 2001). Peer Reviews in Software: A Practical Guide. Addison-Wesley Professional. ISBN 0201734850.