- cross-posted to:
- devops@programming.dev
- cross-posted to:
- devops@programming.dev
Sometimes unused class or function manages to slip into code base. Static code checkers like ruff, flake8 does not have rules for detecting such globally unused code.
I tried using vulture, but it has too many false positives to have it as part of CI/CD pipeline.
I have tried to implement my own, more reliable check for global deadcode detection.
Please let me know what you think about it.
This is great! I really appreciate that it returns a sensible exit code to the shell so that it can potentially fail a build. I also like the ability to maintain a list of excluded names in
pyrpoject.toml
so that you don’t always have to sort through false positives.Would love to see some more output options, like maybe
--quiet
that simply passes/fails and returns the exit code with no output or--count
that either just displays a count or includes a count in the regular output. I guess I could always pipe the output towc -l
instead of having--count
.I’ll see if I can’t get this integrated in our CI system at work this next week.
Thank you for your feedback! Its exactly what I was looking for 👍
I have already added
--count
,--quiet
options and regexp pattern support for--ignore-names
option. Let me know if anything else pops into your mind 😃Wow, nice. Thank you!
Would also be nice if I could use some sort of pattern in the
--ignore-names
option. Apologies if that’s already there and I missed it.Great idea! I will add this feature shortly :)
Just coming back around on the count thing, in order to use
wc -l
, you need to ensure that stderr is piped too. Like:deadcode . --exclude=*/tests,conftest.py --ignore-names-in-files=core/settings.py 2>&1 | wc -l
I ran this against a ~8 month old Django project and it turned up 11 unused names, of which 5 were expected and can be whitelisted. Nice!
From a quick look at the code it looks like it uses regex to extract any name assignments and compares that to usages. This approach seems very limited as it has no understanding of context (e.g. the same name used in multiple places, or special methods like
__add__
on classes that aren’t called manually).I’d be interested to know what false positives in vulture this solves. The main false positives I’ve found with vulture are:
- Names that are publicly exposed in a library but not actually used
- Methods in classes that are called by an external parent class defined in some external module.
- Special cases (for example unittest functions, which aren’t called manually, or fastapi route decorator functions)
I don’t think this project would solve any of those cases (and in some cases I think vulture has special casing to handle things better).
Yes, you are right 👍 Thanks for pointing this out. And yes, my package is only a subset of
vulture
functionality.
Interesting. I’ll have to give it a try.
Currently putting together unit tests for a project and I’m using pytest-cov to identify unused blocks of code (that I need to define tests to invoke). A lot of time code isn’t used but should remain as it has a purpose for a future / anticipated need
I cross-posted to !devops@programming.dev too, hope you don’t mind.
Thank you! I am really glad you did share it. And thanks for a Github star. I really appreciate it :)
Hello, Im confuse how to use deadcode, installed it with pip install deadcode In Spyder console typed ‘deadcode’ or ‘deadcode .’, result: NameError: name ‘deadcode’ is not defined I want to remove unused variable. Thanks
That’s nice, but that’s usually what testing and coverage are for.