avoiding-false-positives

Reduce false positives by verifying three criteria before flagging: trace the execution path showing incorrect behavior, confirm the issue isn't handled elsewhere, and verify correct framework behavior and language semantics. This prevents unnecessary noise from intentional simplicity, framework conventions, and test code.

Recognize framework conventions, intentional simplicity, test code, generated code, and copied patterns as non-issues. Before creating a finding, check whether the pattern aligns with project conventions and framework design rather than indicating a real problem.

Don't flag if you cannot trace an execution path showing actual incorrect behavior, if error handling exists elsewhere like middleware or validators, or if you're uncertain about framework behavior and API contracts. Uncertainty about any criterion means do not create the finding.

Verify by checking three things: can you trace execution showing the bug occurs, is the issue already handled by error boundaries or validators, and are you certain about framework behavior and language semantics. All three must be confirmed to flag safely.

Framework conventions define expected behavior and API contracts. Understanding them prevents flagging correct implementations as issues, reducing noise and preserving focus on genuine problems that violate those conventions or codebase standards.

Yes, apply this during both manual code review and automated analysis. The three-criterion verification—execution path tracing, checking alternate handling, confirming framework semantics—integrates into any review workflow to align findings with project conventions.