Reducing Review Noise

The primary reason teams abandon automated code review tools is notification fatigue caused by minor nitpicks and false positives. ScanDrix is designed from the ground up to prioritize signal over noise.

Follow these proven calibration steps to achieve clean, high-signal reviews.

1. Set the baseline severity threshold

By default, ScanDrix only posts inline comments for issues that match or exceed your configured threshold:

# .scandrix.yaml
review:
  # Options: info, warning, critical
  severity_threshold: warning

• critical: Use this for high-velocity teams. Only security vulnerabilities (SQLi, hardcoded secrets, SSRF) and broken invariant errors are posted.
• warning: Recommended balance. Catches performance flaws, missing transaction boundaries, and unhandled errors.
• info: Style suggestions and optional refactors (recommended only for staging/preview branches).

2. Ignore generated files and vendor directories

Diffs containing minified bundles, lockfiles, or auto-generated Protobuf/GraphQL code clutter review findings. Add an ignore block:

ignore:
  - "**/*.generated.ts"
  - "dist/**"
  - "build/**"
  - "vendor/**"
  - "**/*.pb.go"
  - "package-lock.json"
  - "pnpm-lock.yaml"

3. Limit maximum comments per PR

Prevent overwhelming developers with massive review dumps by setting a hard ceiling:

review:
  max_comments_per_pr: 10

When more than 10 issues exist, ScanDrix surfaces the top 10 highest-severity findings inline and collapses the remainder into a structured expandable summary table at the bottom of the PR description.

4. Use inline suppressions

Developers can suppress specific false positives directly in code using standard comment tags containing the rule ID:

// scandrix-ignore: sec-001 -- safe query constructed with trusted static table constant
const result = await db.query(`SELECT * FROM ${trustedStaticTable}`);

All suppressions are recorded in your organization audit logs for governance reviews.

5. Validate new rules with Dry Run

Never roll out a new organization-wide rule without testing it first! Use the Dry Run simulation feature to evaluate your rule against past pull requests to verify that its hit rate reflects genuine bugs rather than benign code patterns.