Code Review Articles

Alex Marelli from Google gives a presentation (PDF format) about why code reviews are good and how to avoid the common pitfalls. Comes from the perspective inside Google where code reviews are manditory.

S.M. Sohan explains how iterative and incremental code reviews can acheive much of the benefit of Extreme Programming (XP) while taking less time. Although not disparaging of XP techniques, this code review technique might be more acceptable to the powers-at-be who refuse to invest in full-scale pair-programming.

A fun way to do code review over lunch by Ben Northrop. He brings up the idea that each reviewer should be looking for one class of bug, rather than everyone trying to do everything.

An on-going Q & A session over at Stackoverflow about how to tell someone their code needs improvement. This happens all the time in peer code review; you need ways of helping people improve without hurting feelings or becoming defensive.

The Mozilla foundation is known for the high quality of their software including Firefox and Thunderbird. Read their FAQ about why every change is code-reviewed, what they look for in a review, and their process that successfully allows thousands of developers to contribute code while retaining high quality and a maintainable code base.

The vibrant community over at Stack Overflow has been discussing patterns for successful peer reviews. It's nice to see Code Collaborator as the (currently) most-voted answer, but many other responses have great information.

Lynn Bender of GeekAustin.org interviewed Jason Cohen, founder of Smart Bear about why peer code review is useful, where it fits in the development process, and how to get started doing it.

Joshua Segall reacts to recent conversations by Joel Spolsky and Jeff Atwood about whether code reviews are better done off-line with a tool or together in a meeting room.

Paul Tozour writes from his own experience with code reviews as a game developer, explaining how everyone improves from review, not just junior developers, and about why on-line, no-meetings review is better than other traditional forms of review and pair-programming.

Jason Cohen from Smart Bear is the guest editor this month over at embedded.com. This article describes how to build effective peer code review checklists for software projects.

The Jolly Blogger presents a list of five commandments that make code reviews go more smoothly.

The Payment Card Industry Data Security Standards, PCI DSS, is something that by now, even consumers are well aware of. Those six letters can mean the difference between millions in sales for some companies, or millions in losses and fines. On June 30, there is a new revision in the PCI DSS specs, and finally there are some teeth when it comes to web security. No longer will web application security testing be an afterthought, it will become a requirement.

As part of a quality, agile process, all code at Exoweb goes through two layers of peer code review.

One developer's point of view on why peer code review is so valuable, and how typical excuses for not doing code review are faulty.

Jeff Atwood compares pair programming with lightweight code review techniques, giving pros and cons of each and concluding that you've got to do one or the other.

Microsoft MVP Robert Bogue writes about how to deal with the potentially devistating social problems that can arise from peer code review. He describes the approach and mindset for both authors and reviewers that keeps reviews positive and useful without hurting feelings.

Jeff Atwood explains why you just have to do code reviews, backing it up with comments from Steve McConnell and Karl Wiegers.

This lengthy MSDN document gives Microsoft's advice on how to do security audits on ASP.NET applications. Most of the advice is appliable to any web-based application.

Steve McConnell describes how technical code reviews affect not only software quality but how quickly you can get software to a minimum of defects.