1. Principles
   1. Reviewers should favor approving a revision once it is in a state where it definitely improves the overall code health of the system being worked on, even if the revision isn't perfect.
   2. Technical facts and data overrule opinions and personal preferences.
2. Author
   1. Revision
      1. Self-contained, small
         1. Makes a minimal change that addresses just one thing.
         2. The system will continue to work after the revision is checked in
         3. Not so small that its implications are difficult to understand
      2. After automated checks (tests, style, other CI)
      3. Good descriptions
         1. First line: Short summary of what is being done
         2. Body is informative
      4. Refactoring changes should not alter behavior and vice versa
   2. Respond
      1. Don't be offended
      2. Reply to every comment
3. Reviewer
   1. Prompt (within hours) and thorough
      1. Look at every line of code
      2. If you are not in the middle of a focused task, you should do a code review shortly after it comes in
      3. One business day is the maximum time it should take to respond to a code review
         1. First thing the next morning
   2. Areas
      1. Design
         1. Most important
         2. Do the interactions of various pieces of code make sense
      2. Purpose / Functionality
         1. Does it accomplish the author’s purpose
         2. Functions and classes should exist for a reason
         3. Thinking about edge cases, looking for concurrency problems
         4. Parallel programming
            1. Deadlock or race conditions
      3. Implementation / Complexity
         1. Think about how you would solve the problem
         2. Look for abstractions
         3. Think like an adversary
         4. Use libraries or existing product code
         5. Follow standard pattern
         6. Avoid dependencies
         7. Avoid over-engineering
      4. Legibility and style
         1. Thinking about reading experience
         2. Code style
         3. Avoid TODOs
      5. Maintainability
         1. Read the tests
            1. Ask for unit, integration and end-to-end tests
         2. Naming
         3. Backward compatibility
         4. Documentation and Comments
            1. Comments should explain why some code exists, not what some code is doing
            2. Documentation of class or functions should express the purpose of a piece of code
         5. Is the external documentation updated
      6. Good Things
         1. Tell the developer if you see something nice
      7. Security
   3. Comments
      1. concise, friendly and actionable
         1. Balance giving explicit directions with just pointing out problems and letting the developer decide
      2. Explain your reasoning
      3. Encourage developers to simplify code or add code comments instead of just explaining the complexity to you
   4. Steps
      1. 1. Take a broad view of the change
      2. 2. Examine the main parts of the CL
      3. 3. Look through the rest of CL in an appropriate sequence