DEV Community: The Living Algorithms

I Stopped Fearing Legacy Code Once I Could See Its Dead Parts

The Living Algorithms — Wed, 07 Jan 2026 13:20:45 +0000

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.

I stopped reading code and started mapping it (and it saved my sanity)

The Living Algorithms — Sat, 27 Dec 2025 06:16:56 +0000

I was onboarding onto a codebase I didn’t write.

It wasn’t terrible code.
It wasn’t great either.
It was just… big.

Multiple folders, shared utilities, functions calling other functions across files. Nothing unusual, just the kind of project that accumulates over a few years.

I ran into a familiar problem almost immediately.

I wanted to change a function, but before touching it I needed to answer one question:

“What else depends on this?”

I started the usual way.

Go to definition.
Jump to another file.
Search for usages.
Open more tabs.

After a while, I had context, but it was fragile. If I took a break or switched tasks, I’d have to rebuild that understanding again.

That’s when it hit me:
I wasn’t struggling with the code itself.
I was struggling to hold the structure in my head.

Reading code works — until the system gets large

Line-by-line reading is fine for small modules.

But once a project grows, most of the difficulty isn’t inside individual functions. It’s in the relationships:

Which functions call which

Where logic fans out

Which files quietly become central over time

We usually handle this by:

Keeping mental maps

Drawing quick diagrams

Relying on “experience” to feel our way through changes

That works… until it doesn’t.

Mental maps don’t scale.
And diagrams go stale almost immediately.

I kept wishing for a way to just see the structure of a file instead of reconstructing it every time.

The idea: the map should come from the code

I tried sketching things manually.
It helped, but only temporarily.

I looked at existing visualization tools, but most of them required leaving the editor or exporting code. That friction meant I never used them consistently.

The conclusion was simple:

If a map is going to be useful, it has to be:

Generated directly from the code

Always up to date

Available inside the editor

That’s where Codur came from.

Not as a product idea, just as something I wanted while working.

What Codur actually does

Codur is a VS Code extension that generates a visual map of a file’s structure.

It focuses on:

Function relationships

Call flow within a file

How logic connects at a glance

It doesn’t try to explain why the code exists or how to design better architecture. It just answers a simpler question:

“What’s going on here, structurally?”

Under the hood, it uses AST parsing, not regex, so it understands real scope and function relationships instead of guessing from text.

The result isn’t a perfect diagram.
But it’s accurate enough to orient yourself quickly.

That’s the point.

A concrete example

I tested Codur on a file that was around a few hundred lines long.

Nothing scary — just dense.

Looking at the map immediately showed me:

One function acting as a hub

Several helper functions that were purely internal

A couple of calls that were more important than they looked in the code

That saved me time because I knew where not to look.

Instead of reading everything, I could focus on the parts that actually mattered for the change I wanted to make.

Building it was harder than I expected

VS Code extensions look simple from the outside.

They’re not.

Webviews have their own lifecycle issues.
State can disappear unexpectedly.
Performance matters more than you think — parsing on every keystroke is not an option.

Most of the work went into:

Making updates predictable

Avoiding unnecessary re-parsing

Keeping the editor responsive

None of this is particularly glamorous, but it’s what made the extension usable instead of annoying.

What Codur is (and isn’t)

Codur is not:

A replacement for reading code

A documentation generator

A magic fix for messy architecture

It is:

A way to quickly understand structure

A tool for reducing cognitive load

Helpful when you’re working in unfamiliar or large files

I use it when I want to get oriented fast, not when I want deep semantic understanding.

Why I’m sharing this

Codur is still early.

I’m sharing it because I’ve found it useful in my own work, and I’m curious whether it helps other people dealing with similar problems.

If you regularly work in large or unfamiliar codebases, this might be worth trying, even if it only helps with initial orientation.

It’s free, and I’m actively looking for feedback, especially cases where the visualization doesn’t help, feels misleading, or breaks down on real-world code.

VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=thelivingalgorithms.codur

Repository:
https://github.com/thelivingalgorithms/Codur_VsCode_Extension