Open knyazer opened 1 month ago
Some of these actually do exist as Pylint rules and settings: https://docs.astral.sh/ruff/settings/#lint_pylint_max-args
Hmm, true, I didn't notice that!
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.