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

Ignore individual lines #34

Closed
mwermelinger opened this issue Dec 17, 2023 · 4 comments
Closed

Ignore individual lines #34

mwermelinger opened this issue Dec 17, 2023 · 4 comments
Labels
effort: medium These issues require some work priority: low type: enhancement Improve an existing feature
Milestone

Comments

@mwermelinger
Copy link
Member

mwermelinger commented Dec 17, 2023

Most linters permit creating exceptions when we know it's OK to break a rule. This is typically done by adding a comment like # noqa: F401 to disable reporting error F401 just for that line. The exact form of the comment depends on the linter.

In the case of allowed, this would be useful when creating an assignment that contains scaffolding code that students aren't required to understand or change. If the scaffolding code contains non-taught constructs, allowed will report them. This may confuse students and makes it harder to distinguish violations in teacher's code and student's code.

Since allowed doesn't have different error codes, a comment like # allowed should be enough, stating that the constructs in that line are allowed.

@mwermelinger
Copy link
Member Author

A construct like try ... except ... should have the comment on the try line and not report a violation for that line and the except line.

@mwermelinger mwermelinger added the type: enhancement Improve an existing feature label Dec 17, 2023
@mwermelinger mwermelinger added this to the 24J release milestone Jan 8, 2024
@mwermelinger mwermelinger added priority: low effort: high These issues require the most work labels Jan 9, 2024
@mwermelinger
Copy link
Member Author

I don't know how linters robustly check if the end-of-line comment includes noqa: ...: are comments accessible from the AST? As a first approach, we could just try something like line.rstrip().endswith("# allowed"). If that's true, that line isn't further checked.

Of course, how to allow one construct but not another that occurs in the same line, is a different issue :-)

@mwermelinger
Copy link
Member Author

mwermelinger commented Jan 10, 2024

Actually, low effort: just ~5 LOC. The try/except separation was resolved in previous commit.

@mwermelinger mwermelinger added effort: low These issues require the least work and removed effort: high These issues require the most work labels Jan 10, 2024
@mwermelinger
Copy link
Member Author

Forgot to update docs...

@mwermelinger mwermelinger reopened this Jan 10, 2024
@mwermelinger mwermelinger added effort: medium These issues require some work and removed effort: low These issues require the least work labels Jan 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort: medium These issues require some work priority: low type: enhancement Improve an existing feature
Projects
None yet
Development

No branches or pull requests

1 participant