tags:

views:

92

answers:

3

How to improve one's code review capability? Any suggestion from personal experience will help.

What are the common pitfalls or mistakes done by each one of you? How to ensure issues don't get leaked from code review?

+5  A: 
  • peers should be familiar with the code base.
  • change should be well constrained, not too large
  • change should be tested before submit review request
  • process enforcement. no review, no checkin.
  • good tools be http://www.reviewboard.org/

that is my 2 cents.

Dyno Fu
+1  A: 

  • Schedule reviews prior and provide enough time to prepare for review
  • Have automated tools to check things like conformance to naming convention etc.
    (Say for Java code one can use CheckStyle) so that review time can be well spent to find issues with the code logic, architecture, algorithms
  • sateesh
    +1  A: 

    We have recently institutionalised code reviews within our team.

    Some points where we do a review:

    • Complex or critical changes
    • Refactorings

    Every developer has to fill in the "reviewed by" field in our tracking system before setting the task to resolved. If the developer thinks a review isn't required he or she has to fill in the reason why (like: changed a label).

    To elaborate a good code review culture of the team you should include everyone. The review has to be done by a different developer each time if possible. So a personal pitfall is that I find myself being reviewed by the same person each time.

    Thomas Rawyler