Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for vulture-like dead code detection #872

Open
charliermarsh opened this issue Nov 22, 2022 · 12 comments
Open

Add support for vulture-like dead code detection #872

charliermarsh opened this issue Nov 22, 2022 · 12 comments
Labels
plugin Implementing a known but unsupported plugin type-inference Requires more advanced type inference.

Comments

@charliermarsh
Copy link
Member

As a maintainer of a large Python codebase, I found vulture to be really useful, especially for detecting unused functions and unused modules.

This would require us to introduce some new patterns and capabilities that don't yet exist in Ruff, but should! For example, we need to be able to run some analysis over every file (list the used members), then reconcile that analysis post-hoc. We also need to be able to map from references to local modules.

@charliermarsh charliermarsh added plugin Implementing a known but unsupported plugin and removed enhancement labels Dec 31, 2022
@olliemath
Copy link
Contributor

By the way there is a subset of vulture (and pylint) that would be useful even without mapping out the entire codebase, namely this sort of dead-code detection:

def oops():
    return 1
    return 2  # <- guaranteed never to run

@charliermarsh
Copy link
Member Author

Yeah I'm interested in doing this. @MichaReiser shared some links with me around building these kinds of control-flow graphs. I may write it up as a more detailed issue.

@saippuakauppias
Copy link

saippuakauppias commented Jun 8, 2023

+1 we really miss this kind of linter in ruff

The most interesting thing is to find those functions and classes that are forgotten and do not run

@eronning
Copy link

Also +1 on linting these issues in ruff.

@akx
Copy link
Contributor

akx commented Sep 7, 2023

+1 – would be nice.

Being 100% certain about deadness of names (even locals) can be tricky – e.g. PyCharm generally highlights (well, lowlights) unused locals, unless it notices vars(), locals(), etc. being used in the same scope, in which case it just throws its paws up and doesn't do that highlighting anymore.

For globals, it gets even harder because a tricky user could be getattring (or vars().geting) from any given module.

@FilipeBento
Copy link

This would be extremely useful. I understand full implementation requires a lot of work, but checking if methods or variables are unused is very helpful.

@choweth
Copy link

choweth commented Dec 19, 2023

This vulture-like tool is great: https://github.com/asottile/dead

@ofek
Copy link
Contributor

ofek commented Feb 20, 2024

Since this was opened a while ago, have there been any changes internally that would make such an implementation easier?

@dhruvmanila
Copy link
Member

Since this was opened a while ago, have there been any changes internally that would make such an implementation easier?

Not yet. Adding multi-file analysis is a feature that's on our roadmap which will allow us to support this.

@alexbondar92
Copy link

also +1 for this feature

@NeilGirdhar
Copy link

NeilGirdhar commented Sep 18, 2024

If this is implemented, one kind of dead code that is not caught by vulture is when a derived class has a useless override:

class Problem:
    def reward_threshold(self) -> float:
        """The average return threshold at which the problem is considered solved."""
        raise NotImplementedError

class BasicProblem(Problem):  # This class was inserted as part of a refactor.
    @override
    def reward_threshold(self) -> float:
        return 100.0

@dataclass
class GeometryProblem(BasicProblem):
    @override
    def reward_threshold(self) -> float:  # Useless override — this was forgotten during the refactor.
        return 100.0

@MichaReiser MichaReiser added type-inference Requires more advanced type inference. and removed multifile-analysis labels Oct 24, 2024
@MedAzizTousli
Copy link

Any updates on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin Implementing a known but unsupported plugin type-inference Requires more advanced type inference.
Projects
None yet
Development

No branches or pull requests