Code Review英語表現完全ガイド — PRレビューですぐ使える実践表現100+

# 明確な変更要求
- "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..." パターン — やさしく提案
- "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..." パターン
- "What do you think about extracting this into a helper function?"
- "What do you think about using a dataclass here instead?"

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

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

# 些細な事項は "nit:" プレフィックスで表示（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"

# なぜそうしたのか聞くとき
- "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?"

# コードがどう動作するか確認するとき
- "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?"

# テスト関連の質問
- "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?"

# 具体的に称賛する（具体的であるほど良い）
- "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."

# コードとともに代替案を提示する例

# 既存コード:
# for item in items:
#     if item.status == 'active':
#         result.append(item.name)

# レビューコメント:
# "We could simplify this with a list comprehension:
# `result = [item.name for item in items if item.status == 'active']`"

# 代替案を提示する表現
- "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..."

# パフォーマンス問題の指摘
- "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."

# 安全性問題の指摘
- "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) バリエーション
- "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!"

# 条件付き承認
- "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."

# コードレビューでよく使われる略語
LGTM  = Looks Good To Me（承認）
PTAL  = Please Take A Look（レビュー依頼）
WIP   = Work In Progress（作業中）
RFC   = Request For Comments（意見募集）
TIL   = Today I Learned（今日学んだこと）
IIRC  = If I Remember/Recall Correctly（記憶が正しければ）
AFAIK = As Far As I Know（私の知る限り）
IMO   = In My Opinion（私の意見では）
IMHO  = In My Humble Opinion（僭越ながら）
FYI   = For Your Information（参考までに）
WDYT  = What Do You Think?（どう思う？）
ACK   = Acknowledged（確認済み）
NACK  = Negative Acknowledgment（反対）

# Conventional Commits スタイル
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.

# 丁寧に反対意見を表現する
- "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..."

# 正直にわからないと言うとき
- "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?"

# レビュー遅延について
- "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."

# レビュー対象コード:
def get_user(user_id):
    response = requests.get(f"https://api.example.com/users/{user_id}")
    return response.json()["data"]

# 良いレビューコメント:
"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."

# レビュー対象コード:
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

# 良いレビューコメント:
"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?"