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

Names for errors? #102

Open
The-Compiler opened this issue Nov 8, 2022 · 1 comment
Open

Names for errors? #102

The-Compiler opened this issue Nov 8, 2022 · 1 comment

Comments

@The-Compiler
Copy link

One thing I really like about mypy and pylint over e.g. flake8 is that it has names for its errors, which can also be used to ignore them.

If I read # noqa: FURB125, I have no idea what that's supposed to mean without having to look things up. Similarly, if I write a config file, it needs lots of comments to point out what checks I'm disabling/enabling there.

If, however, I see # noqa: furb-no-trailing-return, or somesuch, that makes things much cleaner.

@dosisod
Copy link
Owner

dosisod commented Nov 8, 2022

I think giving names to checks would be a good idea! I agree that FURB125 is a lot less readable compared to furb-no-trailing-return or the like. It also makes it easier on developers who want to talk about a certain check since they don't have to look up the error code beforehand.

I think this would be pretty easy, basically we would just modify the ErrorInfo classes like so:

@dataclass
class ErrorInfo(Error):
    """
    docstring here
    """

    name = "no-trailing-return"  # add this line
    code = 125
    msg: str = "Return is redundant here"

And since the suffix defaults to FURB, we can append furb- to some list for doing lookups later. Then, you would just do:

refurb file.py --disable furb-no-trailing-return

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants