google-code-review-reviewer

Start with the change description to confirm it makes sense, examine the main files for design problems first, then review remaining files in sequence. Approve when the change improves overall code health, even if it is not perfect.

Check design, functionality, complexity, tests, naming, comments, style, consistency, and documentation. Read every line of human-written code and consider the change in the context of the whole system.

Comment on the code rather than the developer, explain why a change is requested, and label severity with prefixes like Nit, Optional, or FYI. Point out problems but let the author design the fix.

Respond shortly after a review arrives unless you are in a focused task, since interruptions are costly. Individual responses matter more than total turnaround; send a quick acknowledgment if a full review must wait.

Ask the author to split a change into smaller dependent changes when it is too large to review in reasonable time. Reject immediately only when the change should not happen at all, and suggest an alternative direction.

First consider whether the author is right, since they are closer to the code. If your suggestion still stands, explain the reasoning further, and insist that new complexity be cleaned up before submission rather than later.