dep-tree VS git-of-theseus

The portion of the code in charge of rendering lives inside the `internal/entropy` (https://github.com/gabotechs/dep-tree/tree/main/internal/ent...).

Force-directed is an algorithm for displaying graphs in a 2d or 3d space, which simulates attraction/repulsion based on the dependencies between the nodes, the wikipedia page explains it really well https://en.wikipedia.org/wiki/Force-directed_graph_drawing

> Love it, I think dependency trees are super underused data for static analysis.

Definitely, specially for evaluating "the big picture" of a codebase

If you like Dep Tree, feel free to stop by the GitHub repository and give it a star. Check out the README and you will find out that Dep Tree is far more than just a cool visualization tool; it can actually help you enforce your code base decoupling!

I am working on dep-tree, a CLI tool for rendering and linting source code file dependency trees, https://github.com/gabotechs/dep-tree, and I recently added support for the Rust language (previously, only TypeScript and JavaScript where supported).

https://github.com/erikbern/git-of-theseus

A tangentially related tool you can use to look at a repo over time is Git of Theseus[1]. It shows things like "what percentage of the code in this repo survives 6 months.

[1]https://erikbern.com/2016/12/05/the-half-life-of-code.html

There're some more in the presentation article: https://erikbern.com/2016/12/05/the-half-life-of-code.html#:...

A kernel line has half-life 6.6 years.

Look at the codebase with Git of Theseus or Codescene

I guess one good example (that was mentioned just yesterday here on HN) would be Flask vs FastAPI: https://news.ycombinator.com/item?id=31953470 - "There are no open issues or pull requests on Flask "

Quick count finds that FastAPI has 48422 lines of code, while Flask has 9995. Flask just achieved "Zero standing issues/PRs" while FastAPI has 1.1K open issues and ~500 open PRs.

Large surface area/API quickly leads to be overwhelmed when you're trying to maintain it. Adding new features/fixing existing ones becomes harder as well.

Best bet to make sure something is maintainable over time is to add as little as possible to it, and if you really have to, make sure you're also removing something at the same time.

Otherwise you need a massive team just to be able to "survive" and not making things rot.

There is this blogpost as well about the "half-life of code": https://erikbern.com/2016/12/05/the-half-life-of-code.html

Someone run that tool on the Clojure codebase as well, and it really shows how well the Clojure codebase has been written, as most code that was initially written is still there and does what it needs, without having to be rewritten.

Some parts of technical debt, you can find with https://github.com/erikbern/git-of-theseus or https://codescene.com/