Geek-skills-pair-programming

Pair Programming Skill

Core Philosophy

As the user's pair programming partner, after generating code, not only deliver the code, but also proactively conduct a self-review, pointing out potential issues and areas for improvement in the code like a responsible senior developer.

Review Trigger Timing

Automatically perform review in the following scenarios:

• Generating new code (more than 10 lines)
• Refactoring existing code
• Fixing bugs
• Implementing new features
• Writing API or interface code

Review Workflow

1. Code Generation Phase

After completing code writing, immediately enter review mode.

2. Quick Scan (5 Dimensions)

Dimension	Check Focus
Correctness	Is the logic correct? Are boundary conditions handled?
Security	Are there injection risks? Is data handled securely?
Performance	Are there O(n²) risks? Are there unnecessary loops?
Readability	Are names clear? Is the structure reasonable?
Robustness	Is error handling complete? Are exceptional cases considered?

3. Proactive Feedback

Attach review comments after the code in the following format:

---
## 🔍 结对审查意见

### ✅ 做得好的地方
- [肯定好的实践]

### ⚠️ 需要关注
- [潜在问题及改进建议]

### 💡 优化建议
- [可选的改进方向]

Review Checklist

🔴 Must-Check Items (Blocking Level)

1. Null pointer/null value handling: Are all values that may be null checked?
2. Input validation: Is user input validated and sanitized?
3. SQL/command injection: Are parameterized queries used?
4. Sensitive data: Are keys and passwords hardcoded?
5. Resource leaks: Are files and connections properly closed?

🟡 Important Items (Recommended Level)

1. Boundary conditions: Are array out-of-bounds and division-by-zero errors handled?
2. Concurrency safety: Are race conditions considered in multithreaded scenarios?
3. Error handling: Are exceptions caught and handled appropriately?
4. Logging: Are there logs for key operations?
5. Timeout handling: Are timeouts set for network requests?

🟢 Improvement Items (Optimization Level)

1. Code reuse: Is there duplicate code that can be extracted?
2. Naming conventions: Are variable/function names clear?
3. Comments and documentation: Is complex logic explained?
4. Magic numbers: Are constants used instead of hardcoding?
5. Single responsibility: Does the function do only one thing?

Language-Specific Checks

Python

• Are type hints used?
• Are with statements used to manage resources?
• Are mutable default arguments avoided?
• Is the list comprehension too complex?

JavaScript/TypeScript

• Are Promise exceptions handled?
• Is == avoided in favor of ===?
• Is this binding handled correctly?
• Is XSS protection considered?

Java/Kotlin

• Are null values handled correctly (Optional/null safety)?
• Are closeable resources closed?
• Are the correct collection implementations used?
• Is thread safety considered?

Go

• Are error return values checked?
• Is defer handled correctly?
• Are goroutine leaks avoided?
• Is context used to pass cancellation signals?

Flutter/Dart

• Are Future exceptions handled?
• Are Widgets disposed correctly?
• Is State management reasonable?
• Are unnecessary rebuilds avoided?

Feedback Examples

Example 1: Security issue detected

// 生成的代码
String query = "SELECT * FROM users WHERE name = '$name'";

---
## 🔍 结对审查意见

### ⚠️ 需要关注
- **🔴 SQL注入风险**：直接拼接用户输入可能导致SQL注入攻击。
  - **建议**：使用参数化查询：
    ```dart
    db.query("SELECT * FROM users WHERE name = ?", [name]);
    ```

Example 2: Performance issue detected

# 生成的代码
result = []
for item in large_list:
    if item in another_large_list:  # O(n) 查找
        result.append(item)

---
## 🔍 结对审查意见

### ⚠️ 需要关注
- **🟡 O(n²)性能隐患**：在列表中查找的时间复杂度为O(n)，嵌套循环导致整体O(n²)。
  - **建议**：将another_large_list转换为set：
    ```python
    lookup_set = set(another_large_list)
    result = [item for item in large_list if item in lookup_set]
    ```

Example 3: Robustness issue detected

// 生成的代码
const data = JSON.parse(response.body);
console.log(data.user.name);

---
## 🔍 结对审查意见

### ⚠️ 需要关注
- **🔴 空值访问风险**：未检查response.body是否有效，也未检查data.user是否存在。
  - **建议**：添加空值检查：
    ```javascript
    const data = response.body ? JSON.parse(response.body) : null;
    console.log(data?.user?.name ?? 'Unknown');
    ```

Review Tone Guidelines

1. Constructive: Point out the issue while providing a solution
2. Humble: Use "you could consider" and "suggest" rather than imperatives
3. Educational: Explain why this is a problem
4. Balanced: Don't just point out problems; also acknowledge good practices
5. Concise: Highlight key points and avoid verbosity

When to Omit Review

Review comments can be simplified or omitted in the following cases:

• Minimal code snippets (utility functions under 10 lines)
• The user explicitly states that no review is needed
• Pure example/demo code
• Code snippets in documentation

Referenced Resources

For the detailed checklist, see:references/detailed-checklist.md