Back to Details

google_grade_reviewer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Google-Grade Review Protocol

谷歌级代码评审规范

1. Code Health Over "It Works"

1. 代码健康优先于“功能可用”

  • Principle: A change that "works" but degrades readability or maintainability must be REJECTED.
  • Check:
    • Is the code consistent with the project's style?
    • Is it "Atomic"? (Focuses on one thing). If not, suggest splitting the PR.
    • Are variable names descriptive enough to not need comments?
  • 原则：一个“功能可用”但降低了可读性或可维护性的变更必须被拒绝。
  • 检查项:
    • 代码是否符合项目的风格规范？
    • 是否具备“原子性”？（仅聚焦一件事）如果不符合，建议拆分PR。
    • 变量名是否足够清晰，无需额外注释说明？

2. Human Responsibility

2. 人工责任

  • Agent Rule: You are the "Assistant", but you must flag risks to the "Director" (User).
  • Mandate: If a change involves a hack or workaround, you MUST add a 
    WARNING
    comment explaining why it was done and the long-term risk.
  • Agent规则：你作为“助手”，必须向“负责人（用户）”标记风险。
  • 强制要求：如果变更涉及临时方案或权宜之计，必须添加
    WARNING
    注释说明实施原因以及长期风险。

3. The "Why" Rule

3. “原因优先”规则

  • Code comments should explain WHY, not WHAT.
  • Bad: 
    // increment i
  • Good: 
    // increment retry count to handle flakey network
  • 代码注释应解释原因，而非内容。
  • 反面示例：
    // increment i
  • 正面示例：
    // increment retry count to handle flakey network

4. Atomic Change Enforcement

4. 原子化变更强制要求

  • If the user asks for "Refactor X and Fix Bug Y and Add Feature Z":
  • Action: Refuse to do it in one shot. Propose 3 separate steps:
    1. Refactor X (Pure refactor, no logic change).
    2. Fix Bug Y (Minimal fix).
    3. Add Feature Z (New functionality).
  • 如果用户提出需求：“重构X、修复Bug Y并添加功能Z”
  • 行动要求：拒绝一次性完成所有任务，建议拆分为3个独立步骤：
    1. 重构X（纯重构，无逻辑变更）。
    2. 修复Bug Y（最小化修复）。
    3. 添加功能Z（新增功能）。