From Wikipedia, the free encyclopedia

Code review is systematic examination (often as peer review) of computer source code intended to find and fix mistakes overlooked in the initial development phase, improving overall quality of software and can also be used as a tool to better develop skills at the same time.

Contents 1 Introduction 2 Examples 3 Criticism 4 Types 5 See also 6 External links

Code reviews can often find and remove common vulnerabilities such as format string exploits, race conditions, memory leaks and buffer overflows, thereby improving software security. Online software repositories, like anonymous CVS, allow groups of individuals to collaboratively review code.

Automated code reviewing software lessens the task of reviewing large chunks of code on the developer by systematically checking source code for known vulnerabilities. Flawfinder and Rough Auditing Tool for Security (RATS) are two well-known examples of code reviewing software.

There are many examples of how code review improved a project. They include:

• Blender3d - A 3D graphics design package greatly improved by the open source development community.
• The Linux Kernel - Once a hobby project written by a Finnish student programmer is now reviewed and improved by hundreds of programmers worldwide.

Some argue that code review is less important when certain rules or secure coding methodologies are followed from the software's inception. The Extreme Programming (XP) approach includes the practice of pair programming, which can be argued to be code review during development. XP proponents argue that other XP practices, such as refactoring and creating tests before even writing the code, produces code that doesn't need to be reviewed or rewritten as often and thus speeds software development.

Also, DOD-STD-2167A listed as a key lesson that code review was not worthwhile. ^{[Quotation from source requested on talk page to verify interpretation of source]} Lausen and Younessi IEEE Software, July/Aug 1998, pg 69-73 concluded that line by line code review was of little value. ^{[Quotation from source requested on talk page to verify interpretation of source]}

Paying programmers to conduct line by line code review is likely to be less productive than other methods of defect removal.^{[citation needed]}

Code review practices often fall into two main categories: formal code review and lightweight code review.

Formal code review, such as a Fagan inspection, involves a careful and detailed process with multiple participants and multiple phases. Formal code reviews are the older, traditional method of review, in which software developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review. However, some critize formal reviews as taking too long to be practical.

Lightweight code review typically requires less overhead than formal code inspections, though it can be equally effective when done properly. Lightweight reviews are often conducted as part of the normal development process:

• Over-the-shoulder – One developer looks over the author's shoulder as the latter walks through the code.
• Email pass-around – The author or source code management system emails code to reviewers.
• Pair Programming – Two authors develop code together at the same workstation, such as is common in Extreme Programming.
• Tool-assisted code review – Authors and reviewers use specialized tools designed for peer code review. Programmers often find tool-assisted code review to be less tedious and more efficient than some other methods.

Many teams that eschew traditional, formal code review use one of the above forms of lightweight review as part of their normal development process.

• Debugging
• Software testing
• Software inspection
• Static code analysis
• Performance analysis

• Exhaustive list of code review tools
• Security code review guidelines
• Code review checklist
• Free book on code review best practices