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

Consider adding too-many-statements ruff rule #25

Open
korikuzma opened this issue Mar 28, 2024 · 3 comments
Open

Consider adding too-many-statements ruff rule #25

korikuzma opened this issue Mar 28, 2024 · 3 comments
Labels
cleanup Changes only making code cleaner & do not change how the code works nor the outputs produced priority:low Low priority

Comments

@korikuzma
Copy link
Member

After this comment, I think we should consider adding this rule

https://docs.astral.sh/ruff/rules/too-many-statements/

too-many-statements (PLR0915)#

Derived from the Pylint linter.
What it does#

Checks for functions or methods with too many statements.

By default, this rule allows up to 50 statements, as configured by the lint.pylint.max-statements option.
Why is this bad?#

Functions or methods with many statements are harder to understand and maintain.

Instead, consider refactoring the function or method into smaller functions or methods, or identifying generalizable patterns and replacing them with generic logic or abstractions.

@korikuzma korikuzma added priority:low Low priority cleanup Changes only making code cleaner & do not change how the code works nor the outputs produced labels Mar 28, 2024
Copy link
Contributor

This issue is stale because it has been open 45 days with no activity. Please make a comment for triaging or closing the issue.

@github-actions github-actions bot added the stale label May 12, 2024
@korikuzma
Copy link
Member Author

I'd still like this. @jsstevenson what do you think?

@korikuzma korikuzma removed the stale label May 13, 2024
@jsstevenson
Copy link
Member

don't personally feel too strongly about this? I'd say it's better to leave room for some subjectivity, so I'd propose a pretty lax limit (something in the range of 60 or 70?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup Changes only making code cleaner & do not change how the code works nor the outputs produced priority:low Low priority
Projects
None yet
Development

No branches or pull requests

2 participants