Page Comparison

...

1. When you create your PR, you will assign someone to review it, based on who you think will do the best job.
2. When you receive a code review request, show the courtesy of responding within a day on when you can complete the code review.
3. You can't send people thousands of lines of code, limit your pull requests to approx. under 500 lines.  This does depend on the language involved.  This is a heuristic, not a hard and fast rule.
4. You need to review every line of code.  You should be able to understand the code.
5. Provide feedback!  Is the code expressive and easy to understand?  
6. Don't let egos get involved.  Having a lot of comments is a good thing, this isn't about someone's code being criticized.  It's about improving code readability, quality and finding bugs.
7. In general, try to get your code reviewed every 48 hours.  
8. It's okay to have several code reviews in a sprint.
9. It's okay to have several code reviews for a single ticket.
10. If you are writing a lot of boilerplate code, you could drop more code in a single PR for review if desired, because the reviewer could learn the syntactic pattern.
11. Don't hold on to your code until the issue is resolved, there is no need to do that.
12. You can use Pseudo code and include your design, the code doesn't have to work.  Comment it out if needed, because we don't want to break tests either.
13. This is NOT an approval process, this is about having a conversation about how you should proceed forward, and is the code of high quality.
14. It is harder to review code than it is to write it.  Please write more comments and description outlining your work.  Reviews take more effort - please write a paragraph about your code.
15. Also if the person that has the context can't do your code review for some reason, the other person will have that much more context when performing the review. 

Related articles

...