GUIDE深度 · Deep dive
Reading a Diff in Code Review
A code-review diff is not better when it is longer. Read the intent and boundaries first, then context; separate formatting, renames and logic changes so noise does not hide bugs.
Three passes
First pass: which files and functions changed, and whether that is in scope.
Second: logic and edge cases; third: naming, comments and tests.
Reduce noise
Commit formatting separately from logic.
Use tools that detect moves so they are not read as delete plus add.
FAQ
What if the diff is too large?
Split the PR; start with tests and critical paths.
Should I read every line?
Read critical paths line by line; skip formatting and generated files.