You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several checks that constrain some numerically-computed properties of the code: the ones from the top of my head are a limit for McCabe complexity (from C901), number of arguments of a function limit (PLR0903), and a number of lines in a single method (PLR0905).
While these constraints are pretty neat, and useful, I would prefer to have more control over them: for example, in machine learning research, it is common to have a lot of parameters in a function, so the 6 arguments constraint is quite annoying, while putting it to e.g. 10 seems to be a good idea.
Besides, I can imagine that when adopting ruff on a new, un-ruffed, codebase one would want to be able to set particular limits for these rules: like, if it is common in the codebase to have insanely long methods, one could just bump up the length to a required value.
I would love the configuration of these rules to be exposed similarly to how line length is exposed, just with a field in a configuration file. Then, I could put something like:
P.S. I'm used to Java checkstyle configuration, which allows to specify an enormous number of different constraints, so I am certainly biased about the necessity of such a feature.
The text was updated successfully, but these errors were encountered:
Still, I think, my point stands: exposing these arguments more ergonomically and on the top-level of the configuration would be great.
Maybe ruff needs a list of "prioritized rules", configurations of which are exposed through the top level config, with generic names that bear no relation to the original pylint-or-whatever rule ids? A human-readable alias of sorts.
While ruff does mostly position itself as simply a reimplementation of tons of linters, it seems interesting to have a nicer interface to configure/add rules, since all the people I know just use ruff as a generic linter, without targeting any particular underlying rule group.
I don't think these settings should be exposed globally. They only apply to the linter and, therefore, should be under [ruff.lint]. However, for the setting to be under ruff lint, they would have to apply to multiple lint-groups which I don't think they currently do.
I do agree that having them in linter specific sections doesn't help with discoverability. This is something we have to solve as part of #1774
This is a feature proposal
There are several checks that constrain some numerically-computed properties of the code: the ones from the top of my head are a limit for McCabe complexity (from C901), number of arguments of a function limit (PLR0903), and a number of lines in a single method (PLR0905).
While these constraints are pretty neat, and useful, I would prefer to have more control over them: for example, in machine learning research, it is common to have a lot of parameters in a function, so the 6 arguments constraint is quite annoying, while putting it to e.g. 10 seems to be a good idea.
Besides, I can imagine that when adopting ruff on a new, un-ruffed, codebase one would want to be able to set particular limits for these rules: like, if it is common in the codebase to have insanely long methods, one could just bump up the length to a required value.
I would love the configuration of these rules to be exposed similarly to how
line length
is exposed, just with a field in a configuration file. Then, I could put something like:into a
pyproject.toml
and be happy about myself.P.S. I'm used to Java checkstyle configuration, which allows to specify an enormous number of different constraints, so I am certainly biased about the necessity of such a feature.
The text was updated successfully, but these errors were encountered: