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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: "allowed_noqa" Config Option #13
Comments
Interesting idea, and wouldn't be hard to add. I'm curious though, why you wouldn't simply add the allowed codes to flake8's ignore list? That way you'd never have to add |
I've come accross one case where an I'm using flake8-broken-line to flag the use of There are however a few exceptions where I'd like to allow |
Of course in this specific case it would be even better if flake8-noqa could just consider the whole multiline string literal as a single line for validation purposes, since we can't add |
@ivanlonel what you're describing sounds like a different issue, there have ben recent improvements in recognizing violations in multi-line tokens (like docstrings). Are you using the latest version? |
Thanks for the quick reply, @plinss. Yes, I'm using flake8-noqa==1.2.8 with flake8==5.0.4 on a fresh Python 3.10.5 venv. Here's a simple example where this happens: |
Adding the Granted, this could also be done with more thorough code reviews, but I like the accessibility of being able to document in the project config what each relevant noqa is meant for without having to memorize or research. Here's an example of where broadly ignoring from overrides import overrides
from some.library import Egg
class Chicken(Egg):
@overrides
def HatchTheEgg(self): # <-- noqa would be appropriate here since this comes from a library method.
return ...
def SaySomething(self): # <-- Real N802 violation in our code that should be fixed.
return "Bacawk!" |
If the code comes from a different tool than Flake8, then adding the code to the ignore list doesn't work. Although maybe that's more #22 ? |
@Avasam I think your comment aligns closer with the other issue than this one. My intention with this ask was to specify a high-level set of approved noqa lines that are even allowed to be used in the project, and would raise a lint flag on the mere existence of anything not specifically approved. This would not modify the behavior of any other checks, but prevents someone in a large team/codebase from ignoring any new kinds of checks without understanding and documenting the modification. |
Hello!
I think a great addition to this library would be an
allowed_noqa
config option (name fungible 馃槅), which allows a project lead to specify a global set of noqa comments that are allowed. This gives a dedicated place for notes and comments to developers regarding how those specific whitelisted noqa items can be used.config.ini
All other noqa comments would be flagged by this plugin. I think this is useful because code review does not capture everything, and having a central location that explains the purpose of each noqa could be helpful.
If I'm missing a Flake feature that already does something like that- my bad and please let me know!
The text was updated successfully, but these errors were encountered: