Code Review Analyzed 1 book to 1 page

Short summary of a cisco case study (pdf):

“The largest case study ever done on lightweight
code review process; data and lessons”

We believe our results allow us to conclude the following:

  • LOC under review should be under 200, not to exceed 400. Anything larger overwhelms reviewers and defects are not uncovered.
  • Inspection rates less than 300 LOC/hour result in best defect detection. Rates under 500 are still good; expect to miss significant percentage of defects if faster than that.
  • Authors who prepare the review with annotations and explanations have far fewer defects than those that do not. We presume the cause to be that authors are forced to self-review the code.
  • Total review time should be less than 60 minutes, not exceed 90. Defect detection rates plummet after that time.
  • Expect defect rates around 15 per hour. Can be higher only with less than 175 LOC under review.
  • Left to their own devices, reviewers’ inspection rate will vary widely, even with similar authors, reviewers, files, and size of the review.

Code Review With Eclipse

The only free and usable plugin: Jupiter
Update-Site: http://csdl.ics.hawaii.edu/Tools/Jupiter/Download
Works good, adds marks/comments in the editor.

Drawback:
Comments are saved as XML in a folder, which must be shared with all other developers (SVN(each comment = new Revision) /Samba)

Conclusion:
Make 1 review on 1 checked out source and commit OR create a samba server and link it to the review-data-folder, so reviews can be shared without commits.

In the editor

Entering a review

Show a review