Code Review Guidelines

Core Principles

1. Be constructive — Focus on improvement, not criticism
2. Be specific — Point to exact lines, suggest alternatives
3. Be thorough — Check functionality, readability, security
4. Be collaborative — Discussion, not gatekeeping

Review Checklist

Functionality

• Does the code do what it's supposed to do?
• Are edge cases handled?
• Are error conditions handled gracefully?
• Does it break existing functionality?

Code Quality

• Is the code readable and self-documenting?
• Are names descriptive?
• Is there unnecessary duplication?
• Does it follow project patterns?

Security

• Is user input validated?
• Any SQL injection / XSS vulnerabilities?
• Are secrets properly handled?
• Are permissions checked?

Testing

• Sufficient test coverage?
• Tests cover edge cases?
• Tests are readable and maintainable?

Performance

• Any obvious performance issues?
• Efficient database queries?
• Memory leaks?

Comment Labels

Giving Feedback

Be specific:

**[suggestion]** The variable `d` on line 45 is unclear. Consider
renaming to `dateOfBirth` to indicate what date this represents.

Explain why:

**[blocking]** Using `any` here defeats type safety. This function
receives user input, so we need proper types.

Suggest alternatives:

**[suggestion]** This loop is O(n²). Consider using a Map for O(n).

Give praise:

**[praise]** Great implementation of retry logic with exponential backoff.

PR Size Guidelines

Anti-Patterns to Avoid

• Rubber-stamping — Approving without reading
• Nitpicking — Blocking on minor style issues
• Bikeshedding — Debating trivial naming choices
• Personal attacks — Criticizing the person, not the code