Back to Details

avoiding-false-positives

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Avoiding False Positives

避免误报

Before Flagging Anything

标记任何问题之前

MUST verify ALL three:
  1. Can you trace the execution path showing incorrect behavior?
  2. Is this handled elsewhere (error boundaries, middleware, validators)?
  3. Are you certain about framework behavior, API contracts, and language semantics?
If you cannot confidently answer all three, DO NOT create the finding.
必须验证全部三项：
  1. 你能否追溯到呈现异常行为的执行路径？
  2. 该问题是否已在其他位置被处理（错误边界、中间件、校验器）？
  3. 你是否对框架行为、API约定以及语言语义完全确定？
如果你无法自信地给出全部三个问题的肯定答案，请勿创建问题记录。

Patterns to Recognize (DO NOT flag)

需要识别的模式（请勿标记）

  1. Intentional simplicity - Not every function needs error handling if caller handles it
  2. Framework conventions - React hooks, dependency injection, ORM patterns have specific rules
  3. Test code - Different standards apply (hardcoded values, no error handling often OK)
  4. Generated code - Migrations, API clients, proto files (only review if hand-edited)
  5. Copied patterns - If code matches existing patterns in codebase, consistency > "better" approach
When uncertain about a pattern, search the codebase for similar examples before flagging.
  1. 有意简化 - 如果调用方已经处理了错误，并非每个函数都需要额外做错误处理
  2. 框架约定 - React hooks、依赖注入、ORM模式都有其特定规则
  3. 测试代码 - 适用不同的标准（硬编码值、无错误处理通常是可接受的）
  4. 生成的代码 - 迁移文件、API客户端、proto文件（仅当是手动编辑的才需要审查）
  5. 沿用的模式 - 如果代码与代码库中现有模式一致，一致性优于“更好”的实现方案
当对某个模式存疑时，标记前先在代码库中搜索类似的示例。

Codebase Conventions

代码库约定

Before suggesting changes:
  1. Check existing patterns - How does this codebase handle similar cases?
  2. Respect established conventions - Even if non-standard, consistency > perfection
  3. Don't flag convention violations unless they cause bugs or security issues
Examples:
  • Codebase uses 
    any
    types extensively → Don't flag individual uses
  • Codebase has no error handling in services → Don't flag one missing try-catch
  • Consistency matters more than isolated improvements
在建议修改之前：
  1. 检查现有模式 - 该代码库如何处理同类场景？
  2. 遵守已确立的约定 - 即使不符合通用标准，一致性也优于完美
  3. 请勿标记违反约定的情况 除非它们会导致bug或者安全问题
示例：
  • 代码库大量使用
    any
    类型 → 不要单独标记某个
    any
    的使用
  • 代码库的服务层没有错误处理 → 不要单独标记某一处缺少try-catch的情况
  • 一致性比孤立的改进更重要

Common False Positives to Avoid

需要规避的常见误报

Do NOT flag when handled elsewhere or guaranteed by framework:
  • Null checks: Language/framework ensures non-null, or prior validation occurred
  • Error handling: Error boundaries exist, function designed to throw, or caller handles
  • Race conditions: Framework synchronizes (React state, DB transactions), or operations idempotent
  • Performance: Data bounded (<100 items), runs once at startup, no profiling evidence
  • Security: Framework sanitizes (parameterized queries, JSX escaping), or API layer validates
When uncertain, assume the developer knows something you don't.
当问题已在其他地方被处理或者由框架做了保障时，请勿标记：
  • 空值检查：语言/框架保证值非空，或者已经提前做了校验
  • 错误处理：已存在错误边界、函数本身就是设计为抛出异常、或者由调用方处理错误
  • 竞态条件：框架做了同步处理（React state、数据库事务），或者操作是幂等的
  • 性能问题：数据量有限（<100条）、在启动时仅运行一次、没有性能分析证据支撑问题存在
  • 安全问题：框架已经做了安全净化（参数化查询、JSX转义），或者API层已经做了校验
当不确定时，假设开发人员知道一些你不了解的上下文。