Trinity:Code review Guidelines

From Notes

Jump to: navigation, search

Guidelines for Conducting Design and Code Reviews:

These are some simple steps to follow during weekly code review meetings. (As best practices are identified during meetings, feel free to add them here.)

  • Take your time to conduct the review.
  • The purpose of review is to carefully understand and analyze design and code.
  • Let the reviewers drive the review.
  • Read the code or design document before the review meeting.
  • The reviewers and their comments must drive a review. If developers are allowed to lead reviews of their own work, other reviewers might miss problems.
  • Unless you are meeting to review some very minor changes, prepare in advance for review meetings. Review meetings for which the reviewers do not prepare beforehand by reading the code or design waste time for everyone involved.
  • Publish your design docs on the project wiki, or other designated site where everyone can easily find and review them.
  • Use a checklist.
    • It is easy to get carried away with certain aspects of a review, for example, focusing exclusively on security, error handling, or style. You might be tempted to move on to other tasks after completing a single aspect. Checklists remind you of the many different aspects that you must cover in your review.
  • Designate a minutes taker for the meeting to take down notes during the sessions.
  • Track all issues found during code reviews.
    • Document issues as work items, as comments in the code, or as issues in the bug tracker. Otherwise, the problems can get lost and you will have gained nothing for the time that you invested in a code review.
  • Avoid major code changes without informing reviewers. i.e. before making major commits into repository.
  • Review all code and designs.
    • To achieve quality in your product, have code and design reviews for all your work. Reviews should include code analysis, unit tests, and documenting the design at the outset.
Personal tools
NSF K-12