##// END OF EJS Templates
api: comment_pull_request, added commit_id parameter to validate status changed on particular commit....
api: comment_pull_request, added commit_id parameter to validate status changed on particular commit. - when using the API and creating a comment with status change it's now possible to pass in commit_id, this will allow validation if status change of pull_request is allowed based on the given commit_id. This solves the case when long running test sends approval of pull request which was already updated several times. The commit_id will now validate for which state the approval was made, and prevent accidental aproval of outdated pull requests.

File last commit:

r1:854a839a default
r1269:26e59d48 default
Show More
reviewing-best-practices.rst
20 lines | 1.0 KiB | text/x-rst | RstLexer
/ docs / code-review / reviewing-best-practices.rst

Code Review - Best Practices

The following is a list of best practices for reviewing code gathered from various sources:

  • Implement a Core Review standard, because the yield of the Code Review phase is 50 to 80% better than that of the Test phase.
  • Review between 100 and 300 lines of code at a time and spend 30-60 minutes doing it for best results.
  • Avoid code review meetings, because meetings contributed only 4% of the defects found in the code inspections.
  • Slow down to a comfortable pace, as reviewers slower than 400 lines per hour are above average in their ability to uncover defects. But when faster than 450 lines/hour the defect density is below average in 87% of the cases.
  • Take a time-out, because defects are found at relatively constant rates through the first 60 minutes of inspection. At that point the checklist-style review levels off sharply; the other review styles level off slightly later. In no case is a defect discovered after 90 minutes.