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.