Intro: why dead code hurts
Dead code is more than “a few unused functions”. It bloats the repo, slows builds, and makes onboarding painful because new devs must mentally sift through code paths that never actually run. Over time, this “code rot” silently drags productivity down and increases the chances of bugs and regressions.
You can open with a short story: you (or a teammate) jumping into a codebase, following a function chain for 20 minutes, and then realizing the entire flow is never triggered in production.
Section 1 – From mapping to pruning
Briefly recap your previous “mapping codebases” idea: you map user flows, not every file.
Explain the next step: once you have a map, you can start asking “which of these streets are never used?”
Connect that to dead code: if 20–30% of the code is unused (real numbers teams report), then every refactor, code review, and bug hunt is harder than it needs to be.
You can position Codur as the tool that turns the abstract “we should clean this up someday” into concrete, safe suggestions.
Section 2 – How Codur’s Dead Code Analysis works
Turn your previous paragraph into a reader‑friendly breakdown:
Uses the TypeScript Language Server, not regex
Codur piggybacks on VS Code’s built‑in TypeScript Language Server, the same engine that powers “Go to Definition” and “Find References”, to scan your entire workspace. Instead of grepping for names, it asks the language server for real symbol references across files, so it can catch unused functions, classes, and components even when they’re imported from far away.
Understands real-world patterns
Many dead‑code tools are noisy because they flag things that look unused but are actually wired in by conventions. Codur is framework‑aware:
React hooks (useXxx) and event handlers (onXxx, handleXxx)
Express routes and middleware
Next.js data‑fetching functions
Test files and helpers
are excluded by default to avoid false positives. It also skips type‑only declarations (export type, interface), barrel exports (index.ts re‑exports), and side‑effect imports, which static analysis often struggles with.
Confidence scores instead of “maybe unused” spam
Every candidate gets a confidence score, and only items above a threshold (for example 70%) are shown in the main list. Confidence‑based ranking is a common way modern static‑analysis tools reduce noise so developers feel safe acting on results.
Local‑first and undo‑friendly
All analysis runs locally inside VS Code: no code upload, no server round‑trips, similar to other language‑server‑driven or on‑prem static analyzers. Cleanup is always reversible: you can open items, delete them with one click, or ignore them, and rely on full undo support if you change your mind.
Section 3 – What developers actually gain
Focus on outcomes, not just features:
Less cognitive load – When a tool automatically highlights code that is never referenced, developers spend less time mentally simulating call chains and more time solving real problems.
Faster onboarding and refactoring – New teammates see a codebase that better reflects reality instead of years of abandoned experiments and feature flags.
Smaller, faster builds – Removing unused modules shrinks bundles and can cut build/test times because the toolchain processes fewer files.
This is where you can tie it back to your “sanity” angle: less dead code means fewer distractions and less fear of changing things.
Section 4 – A quick walkthrough
Outline a concrete flow in 4–5 bullets the reader can imagine:
Open a TypeScript / React / Next.js project in VS Code.
Run Codur’s Dead Code Analysis from the command palette.
Watch it populate a panel with high‑confidence unused functions, classes, and components.
Click into a few, confirm they’re really unused, and delete them with one click.
Run tests; if something breaks, undo is one shortcut away.
Mention that this pairs nicely with mapping: you can run the analysis after mapping a feature, or before a big refactor, to slim down the surface area.
Section 5 – Close with a clear CTA
End with a short, direct invitation:
Ask readers to run Codur on a “scary” legacy repo and share how much dead code it finds.
Offer to write a follow‑up post with deeper implementation details (how you layered on the TypeScript LS, heuristics, confidence scoring, etc.) if there’s interest.
Top comments (0)