The Complete Guide to Code Review English — 100+ Practical Expressions for PR Reviews

# Clear change requests
- "Please rename this variable to something more descriptive."
- "This should be extracted into a separate function."
- "We need to add error handling here."
- "Please add a comment explaining why this is necessary."
- "This constant should be defined at the module level."

# "I wonder..." pattern — gentle suggestion
- "I wonder if we could simplify this by using a list comprehension."
- "I wonder if this would be clearer as a named function."

# "What do you think about..." pattern
- "What do you think about extracting this into a helper function?"
- "What do you think about using a dataclass here instead?"

# "Consider..." pattern
- "Consider using `defaultdict` here to avoid the key check."
- "Consider adding a timeout to this HTTP call."

# "It might be worth..." pattern
- "It might be worth adding a docstring to this class."
- "It might be worth caching this result since it's called frequently."

# Indicate minor issues with "nit:" prefix (non-blocking)
- "nit: trailing whitespace on line 42"
- "nit: this could be a one-liner: `return x if x > 0 else 0`"
- "nit: inconsistent naming — other functions use snake_case"
- "nit: missing newline at end of file"

# When asking why something was done a certain way
- "Could you explain why we need this check here?"
- "What's the reasoning behind using a raw SQL query instead of the ORM?"
- "Is there a specific reason for choosing `threading` over `asyncio`?"
- "I'm curious — why did you go with this approach?"

# When checking how code behaves
- "What happens if `user` is None here?"
- "How does this behave when the list is empty?"
- "Does this handle the case where the API returns a 429?"
- "Will this work correctly with concurrent requests?"

# Test-related questions
- "Do we have test coverage for the error path?"
- "Have you considered adding a test for the edge case where input is empty?"
- "How was this tested? I couldn't find a corresponding test file."
- "Could you add a regression test for this fix?"

# Be specific with praise (the more specific, the better)
- "Nice refactoring! This is much more readable now."
- "Great use of the Strategy pattern here."
- "Love the comprehensive error handling."
- "This is a really elegant solution. Well done!"
- "Excellent test coverage — especially the edge cases."
- "Good catch on that race condition!"
- "TIL about this API — thanks for introducing it!"
- "This abstraction is going to save us a lot of time."

# Example of presenting an alternative with code

# Existing code:
# for item in items:
#     if item.status == 'active':
#         result.append(item.name)

# Review comment:
# "We could simplify this with a list comprehension:
# `result = [item.name for item in items if item.status == 'active']`"

# Expressions for suggesting alternatives
- "An alternative approach would be to use..."
- "You might want to look into using X instead."
- "One option is to..., which would give us..."
- "Have you considered using X? It handles Y automatically."
- "A simpler way to achieve this would be..."

# Pointing out performance issues
- "This creates a new list on every iteration. Consider moving it outside the loop."
- "This O(n squared) approach might be slow for large datasets. A set-based lookup would be O(n)."
- "We should use `str.join()` instead of string concatenation in a loop."

# Pointing out safety issues
- "This looks like it could be vulnerable to SQL injection."
- "We should validate the input before passing it to the shell command."
- "This secret should not be hardcoded — let's use environment variables."

# LGTM (Looks Good To Me) variations
- "LGTM!"
- "LGTM — just one minor nit, but nothing blocking."
- "Looks good to me! Nice work."
- "Approved! Clean implementation."
- "LGTM with the suggested change. Feel free to merge after."
- "Ship it!"

# Conditional approval
- "LGTM once the test is added."
- "Approved with minor suggestions — up to you whether to address them."
- "Looks good overall. Just the one blocking comment about error handling."

# Common abbreviations in code reviews
LGTM  = Looks Good To Me (approval)
PTAL  = Please Take A Look (review request)
WIP   = Work In Progress (in progress)
RFC   = Request For Comments (requesting feedback)
TIL   = Today I Learned (something new)
IIRC  = If I Remember/Recall Correctly (if I recall)
AFAIK = As Far As I Know (to my knowledge)
IMO   = In My Opinion (in my opinion)
IMHO  = In My Humble Opinion (in my humble opinion)
FYI   = For Your Information (for reference)
WDYT  = What Do You Think? (what do you think?)
ACK   = Acknowledged (acknowledged)
NACK  = Negative Acknowledgment (disagreement)

# Conventional Commits style
feat: add user authentication via OAuth2
fix: resolve race condition in cache invalidation
refactor: extract payment logic into separate service
docs: update API documentation for v2 endpoints
perf: optimize database queries for user dashboard
test: add integration tests for payment flow
chore: upgrade dependencies to latest versions

## What

Brief description of what this PR does.

## Why

Explain the motivation. Link to issue/ticket if applicable.

## How

Describe the approach taken and any important design decisions.

## Testing

- [ ] Unit tests added/updated
- [ ] Integration tests pass
- [ ] Manual testing done (describe what was tested)

## Screenshots (if applicable)

Before / After screenshots for UI changes.

## Notes for Reviewers

Any specific areas where you'd like focused feedback.

# Expressing disagreement politely
- "I see your point, but I think X might be more appropriate here because..."
- "I respectfully disagree — here's my reasoning: ..."
- "That's a valid approach, but I have concerns about..."
- "I understand the trade-off. Let me explain why I went this route..."

# Being honest about not knowing
- "I'm not familiar with this pattern — could you point me to a reference?"
- "I'm not sure I understand this part. Could you walk me through it?"
- "This is a bit over my head. Can you add a comment explaining the logic?"

# About delayed reviews
- "Sorry for the delayed review — I'll take a look today."
- "Apologies, this slipped through my notifications. Reviewing now."
- "I need a bit more time to review this thoroughly. ETA: tomorrow morning."

# Code under review:
def get_user(user_id):
    response = requests.get(f"https://api.example.com/users/{user_id}")
    return response.json()["data"]

# Good review comment:
"What happens if the API returns a non-200 status code?
We should add error handling here. Something like:

response.raise_for_status()  # Raises HTTPError for 4xx/5xx

Also, `response.json()["data"]` will raise a KeyError
if the response doesn't contain a "data" field.
Consider using `.get("data")` with a sensible default."

# Code under review:
def find_duplicates(items):
    duplicates = []
    for i in range(len(items)):
        for j in range(i + 1, len(items)):
            if items[i] == items[j] and items[i] not in duplicates:
                duplicates.append(items[i])
    return duplicates

# Good review comment:
"This has O(n squared) time complexity, which could be a problem
for large lists. Here's a more efficient approach using
Counter from collections:

from collections import Counter
def find_duplicates(items):
    return [item for item, count in Counter(items).items() if count > 1]

This runs in O(n) time. WDYT?"