DEV Community

xarcho
xarcho

Posted on

I built a CLI that finds dying files in your codebase

#python #cli #devtools #opensource

Every codebase has files that nobody owns. Files too complex to
understand. Files last touched 3 years ago by someone who left.
They never show up in sprint planning — but they cause the most
bugs, the slowest onboarding, and the worst incidents.

I built deathbed to make them visible.

What it does

Run it inside any git repo:

pip install deathbed
cd your-project
deathbed
Enter fullscreen mode Exit fullscreen mode

You get a full file health report scored across 6 metrics:

  • Size — lines of code
  • Age — days since last commit touched this file
  • Churn — how many times it's been modified
  • Complexity — cyclomatic complexity via radon
  • Authors — how many unique people have touched it
  • Tests — whether a corresponding test file exists

Each file gets a health score from 0-100 with a plain-English
diagnosis like "complexity graveyard", "legacy ghost", or
"too many cooks".

Why I built it

I kept inheriting codebases with no idea where to start.
Which files are safe to touch? Which ones will break everything?
Which ones does nobody understand anymore?

No tool answered that question simply. So I built one.

It's completely free and offline

No API key. No config file. No account. Just:

pip install deathbed
Enter fullscreen mode Exit fullscreen mode

Try it on a repo you know 

git clone https://github.com/pallets/flask
cd flask
deathbed
Enter fullscreen mode Exit fullscreen mode

Some of the results might surprise you.

GitHub: https://github.com/NikoloziKhachiashvili/deathbed
PyPI: https://pypi.org/project/deathbed

Top comments (1)

Collapse
 
trinhcuong-ast profile image
Kai Alder •

This is exactly the kind of tool I wish I had when I joined my current team. We had this 2000-line "utils.js" that everyone was afraid to touch — turns out it hadn't been modified in 18 months and had 14 different authors. Classic "too many cooks" situation.

The combination of age + complexity + author count is clever. High churn alone isn't necessarily bad (could mean active development), but high churn + high complexity + many authors = ticking time bomb.

Feature request: would love a --output json flag for CI integration. Imagine failing a build if any file drops below a health score threshold, or tracking file health over time in a dashboard.

Gonna try this on our monorepo tomorrow. Already know which files will be at the bottom 😅