Code Diff Review Before Merging: A Practical Checklist

A code diff is a compressed story about behavior change. Start by asking what user-visible or system-visible behavior is different after this patch. If the answer is unclear, the review is not ready for style comments.

Look for changed conditions, removed checks, new defaults, data migrations, retries, permissions, caching, and error paths. These changes often matter more than formatting.

For each changed function or component, identify the inputs it accepts and the outputs or side effects it produces. Then check what happens with empty input, malformed input, slow dependencies, duplicate requests, and partial failure.

This method catches bugs that line-by-line reading misses. A single added branch can be correct locally and still break a caller that expected a previous return shape.

Tests should prove the new behavior, not only execute the new code. A useful test has a clear scenario, meaningful assertion, and at least one case that would fail if the implementation were removed.

When tests are missing, ask whether the change is low risk or merely untested. Those are different statements. A small permissions change can be high risk even if it touches one line.

Before merge, scan for logging changes, analytics changes, feature flags, environment variables, dependency updates, and performance-sensitive loops. Code that passes tests can still be hard to operate if it fails silently or creates too much noise.

A good review comment explains the risk and suggests a concrete check. "Could this return undefined when the API times out?" is more useful than "this looks risky."