Avoiding False Positives
Before Flagging Anything
MUST verify ALL three:
- Can you trace the execution path showing incorrect behavior?
- Is this handled elsewhere (error boundaries, middleware, validators)?
- Are you certain about framework behavior, API contracts, and language semantics?
If you cannot confidently answer all three, DO NOT create the finding.
Patterns to Recognize (DO NOT flag)
- Intentional simplicity - Not every function needs error handling if caller handles it
- Framework conventions - React hooks, dependency injection, ORM patterns have specific rules
- Test code - Different standards apply (hardcoded values, no error handling often OK)
- Generated code - Migrations, API clients, proto files (only review if hand-edited)
- 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.
Codebase Conventions
Before suggesting changes:
- Check existing patterns - How does this codebase handle similar cases?
- Respect established conventions - Even if non-standard, consistency > perfection
- 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
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.
1---2name: avoiding-false-positives-23description: Prevents false positive findings by recognizing framework patterns, codebase conventions, and common non-issues. Use when uncertain whether something is a real issue.4---56# Avoiding False Positives78## Before Flagging Anything910**MUST verify ALL three:**11121. Can you trace the execution path showing incorrect behavior?132. Is this handled elsewhere (error boundaries, middleware, validators)?143. Are you certain about framework behavior, API contracts, and language semantics?1516**If you cannot confidently answer all three, DO NOT create the finding.**1718## Patterns to Recognize (DO NOT flag)19201. **Intentional simplicity** - Not every function needs error handling if caller handles it212. **Framework conventions** - React hooks, dependency injection, ORM patterns have specific rules223. **Test code** - Different standards apply (hardcoded values, no error handling often OK)234. **Generated code** - Migrations, API clients, proto files (only review if hand-edited)245. **Copied patterns** - If code matches existing patterns in codebase, consistency > "better" approach2526**When uncertain about a pattern, search the codebase for similar examples before flagging.**2728## Codebase Conventions2930**Before suggesting changes:**31321. **Check existing patterns** - How does this codebase handle similar cases?332. **Respect established conventions** - Even if non-standard, consistency > perfection343. **Don't flag convention violations** unless they cause bugs or security issues3536**Examples:**3738- Codebase uses `any` types extensively → Don't flag individual uses39- Codebase has no error handling in services → Don't flag one missing try-catch40- Consistency matters more than isolated improvements4142## Common False Positives to Avoid4344**Do NOT flag when handled elsewhere or guaranteed by framework:**4546- **Null checks**: Language/framework ensures non-null, or prior validation occurred47- **Error handling**: Error boundaries exist, function designed to throw, or caller handles48- **Race conditions**: Framework synchronizes (React state, DB transactions), or operations idempotent49- **Performance**: Data bounded (<100 items), runs once at startup, no profiling evidence50- **Security**: Framework sanitizes (parameterized queries, JSX escaping), or API layer validates5152**When uncertain, assume the developer knows something you don't.**
majiayu000