Improvements to rule docs: versions and fix safety #11367
inoa-jboliveira
started this conversation in
Ideas
Replies: 1 comment 2 replies
-
👋 Welcome
|
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi everyone, I wanted to suggest two improvements to Ruff rules documentation. I find myself using this page almost daily because we are refactoring a large (>1MLOC) project and we are adding rules bit by bit.
I would like to know when a rule was made available, became stable, had changes to it (e.g. v0.1.2 experimental, v0.2.0 became stable, v0.2.4 behavior changed when foo is greater than bar) and also when it was deprecated and/or removed.
This one is quite important because we tend to update ruff very often here.
Have the docs explain why a fix is considered unsafe vs when it is safe.
I believe safety is defined when there are no behavior changed as opposed to unsafe fix which would perform a different but similar operation. Lets say if bytecode changes between two source codes, behavior changes and the rule is deemed unsafe. Right?
In this case, it would be extremely useful if the rule said how the behavior is changing. E.g. rule TID252 changes relative imports into absolute, but sometimes the top level name clashes with another package and the final imported package may be different than the one intended.
That allows the developer to know what to look for when checking a fixed version of the code.
Bonus:
Show different icons for when the fix is safe, unsafe or may be either one depending on the code (e.g. blue, red or yellow hammer and wrench icon)
https://docs.astral.sh/ruff/rules
Beta Was this translation helpful? Give feedback.
All reactions