General Code Review Skill

A comprehensive code review methodology based on Google's engineering practices. Follow these 5 steps to perform effective and thorough code reviews.

Step 1: Pre-screen

Before diving into the code, perform a quick pre-screening:

Check Size

• Reasonable size: A change list of ~300 lines of code is typically reasonable
• Too large: Larger CLs should be strongly discouraged unless necessary
  • Leave a comment asking if the CL can be broken down into smaller, logically complete parts
  • Ask for the reason if breaking down is not possible
• Small is OK: Even single-line changes are fine as long as they are logically complete

Verify You're the Right Reviewer

Ask yourself:

• Am I familiar enough with this code area?
• Do I understand the language, environment, and context?
• Is there someone better suited to review this?

If you're not the ideal reviewer but no one else is available, prepare to quickly learn about the unfamiliar aspects.

Step 2: Understand

After pre-screening, focus on understanding the change from the author's perspective.

Purpose

Ask: "Do I know the overall purpose of this CL?"

• The purpose should be clearly stated in the CL description
• If unclear, request clarification
• Even self-explanatory code needs a clear description for future maintainers
• Remember: even the author may need to refer back to the description later

Workflow Context

Ask: "Was I expecting this CL? Does it match my expectations?"

Consider:

• Is this CL part of a larger project or design doc?
• Does it align with the task distribution and design documentation?
• Are there dependencies mentioned?
  • Other changes that need to happen before this CL can function
  • Other CLs that are blocked by this change

Design Decisions

Verify that important design decisions are:

• Documented in the code description
• Explained with rationale when non-obvious

Step 3: Verify

Now verify the implementation matches the stated intent.

Code-Description Alignment

• Verify the code does what the description says
• Flag any discrepancies between stated purpose and actual implementation

Test Coverage

Verify relevant tests exist for:

Category	What to Check
Design decisions	Tests that validate key architectural choices
Important defaults	Tests for default values and their behavior
Complex logic	Tests for intricate algorithms or business logic
Edge cases	Zero, null, empty, boundary conditions, if-statement edges

Step 4: Optimize

Look for opportunities to improve the code's efficiency and maintainability.

Logic Optimization

• Can the algorithm be simplified?
• Are there unnecessary computations?
• Is the control flow optimal?

Library Usage

• Is the best library being used for this task?
• Are there more appropriate or efficient alternatives?
• Is the library being used correctly and efficiently?

Step 5: Check Style

Final pass for code style and conventions.

Style Checklist

• Follows project/team coding standards
• Consistent naming conventions
• Proper formatting and indentation
• Clear and helpful comments
• No dead code or debugging artifacts

---

Quick Reference Checklist

□ Pre-screen
  □ Size reasonable (~300 lines)?
  □ Am I the right reviewer?

□ Understand
  □ Purpose clear in description?
  □ Expected in current workflow?
  □ Design decisions documented?

□ Verify
  □ Code matches description?
  □ Tests cover design decisions?
  □ Tests cover defaults and edge cases?

□ Optimize
  □ Logic optimizable?
  □ Library choices optimal?

□ Check
  □ Style guidelines followed?

---

Acknowledgment: This methodology is based on reflections from working at Google, with thanks to mentors and teammates who helped improve these code review skills.