Code Review Best Practices

Code review is examining a teammate's code before it merges. Great reviews catch bugs early, improve design, share knowledge across the team, and maintain quality standards. It is one of the most valuable skills a developer can build.

01.How to Review Code Well

Read the PR description first to understand intent and context before reading any code. Review logic and architecture — not just style (linters handle style). Ask questions rather than demanding: "Could this be a race condition if two users click simultaneously?" Be specific: cite file names and line numbers. Approve good things too — positive reinforcement matters. Distinguish blocking issues from optional suggestions.

Commit Timeline

a1b2c3d

init

b2c3d4e

feat

c3d4e5f

fix

d4e5f6a

HEAD

02.How to Submit Reviewable PRs

Keep PRs small and focused on one change — under 400 lines is ideal (large PRs get poor reviews). Write a clear description explaining why the change was needed. Test your own code thoroughly before requesting review. Respond to every comment — even just "done" or "good point, will address separately". Never force-push after review starts.

Branch Visualization

main

feature

HEAD

Commands

commands — click to reveal output

gh pr review 23 --approve

Approve a PR via the GitHub CLI

gh pr review 23 --request-changes --body "Please add unit tests for the edge cases"

Request changes with explanation

gh pr comment 23 --body "Could this be null on first render? Line 42."

Leave a review comment

git diff main...feature/login

Preview what a PR would change before starting review

git log main..feature/login --oneline

See all commits in the PR branch

▼ show output

KNOWLEDGE CHECK

What is the recommended maximum PR size for effective code review?

Rate this lesson:

Previous Next Lesson