Vulture: Find Dead Python Code | Hacker News Reader

Vulture: Find Dead Python Code

github.com

78 pointspolm2321 comments

I ran this on a Flask app. The app has no linting issues and decent test coverage. Vulture reported 192 incidences of unused methods/classes/variables/functions, all at "60% confidence" (whatever that means). There might be some legitimately-unused code in there, but this is almost entirely false positives, with the same "confidence".

It seems like people build giant whitelists when using it with Flask, Django, and other frameworks. Given the volume of false positives, it seems like a maintenance burden to me.

Maybe there's some trick to using it effectively, but it's not obvious to me.

I've had some success using it in a Django app where I generate a whitelist from my main branch, and then I run vulture on my feature branch just before I open up a pull request. This way, it doesn't matter how many false positives there are because I'm only really trying to check if my changes cause any new issues. It's still not as good as other languages with better static analysis tools, but it's better than nothing.

In my experience, you have to set the threshold at 100%. But then it will rarely find anything. It is not essential in CI like pyflakes.

When it works, it’s a fantastic tool. I like pairing it with codespell, interrogate, bandit, and a few other tools to get a broad idea of how my codebase is doing on different fronts.

With that said, lately I’ve had issues using vulture on larger projects with various errors, so hopefully they’ll continue to develop it and address those.

This tool seems interesting, but I haven’t yet figured out how to configure it to work with Django’s dynamic nature. If anyone has had good success I’d love to hear more!

Vulture has to also inspect the template files for this to work, which is probably out of the scope of the project.

Pycharm handles django projects pretty well "find usages" is a somewhat reverse way of doing it though

It's a pity it only supports Python >= 3.6. Large codebases with dead code are usually from the 2.7 era.

Py2.7 is already dead code, vulture is redundant there... /s

Does that mean it should just report 100% confidence on every line of code?

That could be confusing as it may look like other ordinary really dead code. I propose 110% instead.

Vultures are attracted to code smell.

https://en.wikipedia.org/wiki/Code_smell

I wish that code smells were a sign that this is about to become dead, but where I work that’s not the case :(

Some lists of links to other static analysis tools for Python:

https://analysis-tools.dev/tag/python https://github.com/collab-qa/check-all-the-things/blob/maste...

It seems a bit ... dead itself. There's a few issues there that haven't really been addressed in a long time.

Definitely a cool idea though, but a little underwhelming when all it found for me was a bunch of unused variables (the boilerplate context manager arguments). And this is a fairly large Python codebase it was running over.

> Due to Python's dynamic nature, static code analyzers like Vulture are likely to miss some dead code. Also, code that is only called implicitly may be reported as unused.

Note that this problem is generally undecidable, so no tool will ever find all dead/non-dead code accurately.

I feel unit test coverage is a better approach to this problem.

A unit test covering code doesn't mean the code is actually used, and some code isn't feasible to cover in unit tests.

This doesn't really help. I've found plenty of code before that isn't marked by the IDE/linters as unused because it's called by a unit test, but nothing else.

Well atleast the code will be used then. Fingers crossed it already has a unit test, so once the dead code is remove the test can be too

If I have tests for everything coverage is 100% regardless of whether the functions are used or not

Reply on news.ycombinator.com