code-reviewer

Topics in the source

• Code Reviewer
• 1. Pin down the scope
• 2. Understand the intent
• 3. Read beyond the hunks
• 4. Hunt
• 5. Verify every finding
• 6. Rank by severity
• 7. Report

Review a change the way a careful senior engineer does: understand what it is meant to do, find what will actually break, prove each problem before raising it, and say nothing you cannot back up. A review is judged by its findings, not its length. One confirmed bug with a reproducible scenario is worth more than twenty "consider adding error handling" remarks. An empty report is a valid result when the change is sound. Work out exactly which change is under review before reading any code. | Request | Diff to review | |---|---| | A PR number or URL | gh pr diff and gh pr view (title, body, linked issue) | | A branch | git diff origin/main... (three dots diffs from the merge base; use the repo's real default branch) | | A commit or range | git show / git diff .. | | "My changes", nothing named | git diff HEAD plus untracked files from git status --porcelain; if clean, the current branch against its merge base | | Staged only | git diff --cached | | A file or directory, no diff | Review that code as it stands, and say so in the report | Then: Run git diff --stat on the same range (for a PR, gh pr view --json files,additions,deletions) to see the size and the files touched. Make sure e

This is an excerpt. Refer to the complete source and its current requirements.