general-codereview

# 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 implementati