timequity/code-review

Code Review

Core Principle

Technical correctness over social comfort.

Don't say "Great point!" or "You're absolutely right!" — analyze the feedback technically and respond with substance.

Review Checklist

□ Does it work? (logic, edge cases)
□ Is it secure? (injection, auth, secrets)
□ Is it tested? (coverage, edge cases)
□ Is it readable? (naming, structure)
□ Is it maintainable? (complexity, coupling)
□ Does it follow patterns? (consistency)

Issue Severity

| Level | What | Action | |-------|------|--------| | Critical | Security holes, data loss, crashes | Must fix before merge | | Important | Bugs, performance issues, bad patterns | Should fix | | Minor | Style, naming, small improvements | Nice to have | | Nitpick | Personal preference | Comment only, don't block |

Giving Feedback

# Good feedback format:

**Issue**: [What's wrong]
**Why**: [Why it matters]
**Suggestion**: [How to fix]

# Example:
**Issue**: SQL query uses string concatenation
**Why**: Vulnerable to SQL injection
**Suggestion**: Use parameterized queries:
`db.query('SELECT * FROM users WHERE id = $1', [userId])`

Be Specific

# BAD
"This code is confusing"

# GOOD
"The variable `data` doesn't describe what it contains.
Consider renaming to `userProfiles` to match its type."

Praise Meaningfully

# BAD
"LGTM!" (says nothing)

# GOOD
"Clean extraction of the validation logic into a separate function —
makes it much easier to test."

Receiving Feedback

Don't

• Take it personally
• Argue without investigating
• Dismiss without explanation
• Say "You're right!" without checking

Do

• Investigate the concern technically
• Test the suggested approach
• Explain your reasoning if you disagree
• Ask clarifying questions

# Good response to feedback:

"I tested this approach and [result].
The original implementation handles [edge case] because [reason].
However, your suggestion would work if we also [modification].
Should I make that change?"

Verification Before Claiming Done

Before saying "done" or "fixed":

□ Run tests locally
□ Check the specific scenario mentioned
□ Verify the fix doesn't break related code
□ Test edge cases

PR Description Template

## What

[Brief description of changes]

## Why

[Motivation, link to issue]

## How

[Implementation approach]

## Testing

- [ ] Unit tests added/updated
- [ ] Manual testing done
- [ ] Edge cases covered

## Screenshots

[If UI changes]

Quick Commands

# Prepare review (get diff stats)
git diff main...HEAD --stat
git log main..HEAD --oneline

# Review specific commits
git show <sha>
git diff <sha1>..<sha2>