Detect dead code before merge.
See how dead code fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.
radar scan . --quickWhat dead code means here.
The dead code rule identifies review patterns that can create exploitable behavior or hide material maintenance risk, then returns the affected location, severity, confidence, and remediation context.
Evidence to inspect
Use “Detect dead code before merge.” as the scope for this decision: verify the input, finding detail, workflow handoff, and product boundary before you install or buy.
Check this risk locally
Coverage and concrete signals
Detect unreachable or unused paths that hide stale behavior and review risk.
- Audience: Developers and reviewers deciding how to handle dead code findings before merge.
- Evidence to inspect before you trust the result.: Confirm the path is unreachable or unused across entry points, tests, and configuration, then remove it in a focused change.
- Boundary: Reflection, plugin loading, and feature flags can hide live references; check runtime registration and deployment configuration before deleting or suppressing.
- Rule ID: RADAR-HEALTH-DEAD
Risky pattern / Safer pattern
dead code: A useful result must be explainable to a developer and portable to the next review surface. Inspect the concrete evidence below before changing team policy.
From local signal to shared gate.
dead code: Use the smallest workflow that proves value. Each later step should reuse evidence the team already understands. Confirm the path is unreachable or unused across entry points, tests, and configuration, then remove it in a focused change.
radar scan . --quick
radar scan . --format sarif --fail-on highPrimary sources
Validate the workflow on your own code.
Apply this page’s evidence to one real repository. For “Detect dead code before merge.”, confirm which finding is produced, whether the proposed next step is reproducible, and where local scanning, reports, agents, or CI should stop or expand.