Option to opt in to showing error codes or show error codes in addition to rule names

Hi!

I have a big DX regression in the recent ruff releases.
I shared my concerns here in some other issue, but I feel like it deserves its own issue.
#26139 (comment)

Right now the recent change from errors codes that we had for years suddenly changed to some random names. Older codes are not even showed anymore in the ruff check output.

This is how it affects my workflow, imagine this file:

print = 1

It produces this report:

» ruff check ex.py
builtin-variable-shadowing: Variable `print` is shadowing a Python builtin
 --> ex.py:1:1
  |
1 | print = 1
  | ^^^^^
  |

Found 1 error.

So, if I want to ignore this error with its regular error code, I would need to call ruff rule builtin-variable-shadowing to know it. And I have to do that on ALL the error codes that I want to ignore and don't remember by heart.

This literally takes me ages to do. I now spend like dozens of minutes everyday on this. And I really don't like it :)

Why do I care about the older codes?

Because I use flake8 together with ruff (because ruff still does not have a plugin system and does not support wemake-python-styleguide and several other tools that I use daily) Ruleset Suggestion: wemake-python-styleguide #3845 Using these two styles of ignores together is a mess. Compare an older style:

print = 1  # noqa: WPS001, A001

With the new style:

print = 1  # noqa: WPS001, builtin-variable-shadowing

These names are too long, if you ignore several ignores on the same line (I have 3 and even up to 5 in my current project), it becomes quite unreadable. Especially given that a lot of the times it shares the line with # type: ignore and maybe even some other comments:

Short and easy to manage:

Very long comments:

AI tools do not use newer codes by default, so it is a mess of older and newer codes if you use AI. I have to force all agents to use the same style. It does not quite work 100% of the times.
Drop in parity with flake8 was promised. Please, keep it. Quoting your README:

Drop-in parity with Flake8

Please, let's make it at least configurable. With the old behavior as the default preferably.

Okay, I suggest we split this issue in two:

For having some way of showing error codes in the output. Either by having a configuration options or showing both
That each rule has an error code

That allows us to get a better sense for how important each of these aspects are to users

Thanks for the detailed writeup and feedback.

We don't plan on forcing you to use human readable names. Instead, we plan on adding a on-by-default rule that encourages migrating from noqa to ruff:ignore comments (including using human readable names), but you can turn it off if you prefer using human readable names. ruff:ignore comments mitigate the length problem to some extend, because you can place them on their own line, like so:

# ruff:ignore[undefined-name, quoted-annotation]
def some_function() -> 'Undefined': ...

Forward looking. We'll most likely stop adding codes for ruff only rules in the future. That's the only place where you'd be forced to use a ruff:ignore comment. But we'll keep supporting the codes for rules with upstream linters, so that you can use Ruff alongside flake8 etc.

The main feedback I'm hearing is that what you miss is seeing the rule codes in the output. We considered showing both, but it makes the first line even longer. But maybe that's not an issue? We could consider including both instead, if that would address all your concerns.

Yes, short write up:

I want to keep optional # noqa comments for differnt tools in one place (it is fine if I can just disable the new rule for # ruff:ignore comments and keep the older ones)
I want to be able to use short flake8-styled error codes for all the ignores
I want to see the short flake8-styled error codes on errors

I am fine with this being configurable / not default :)

I want to keep optional # noqa comments for differnt tools in one place (it is fine if I can just disable the new rule for # ruff:ignore comments and keep the older ones)

This will be possible with our current proposal

I want to be able to use short flake8-styled error codes for all the ignores

You'll be able to do this for all rules with upstream linters. You might not be able to do this for new rules. How important is this for you? I'm asking because maintaining both codes and names is a bit cumbersome. But it's not incredible hard.

I want to see the short flake8-styled error codes on errors

I think that's the main case where we need to find a solution for

How important is this for you?

It is pretty important :)

both codes and names is a bit cumbersome. But it's not incredible hard.

It will give users more freedom at the cost of mainaining orderer (structured?) error codes :)

Okay, I suggest we split this issue in two:

For having some way of showing error codes in the output. Either by having a configuration options or showing both
That each rule has an error code

That allows us to get a better sense for how important each of these aspects are to users

Related to the new #1773 preview feature

Just wanted to echo Micha's thanks for the detailed feedback!

This only addresses a very small aspect of it, but in case you or others encountering this didn't know, the diagnostic name is actually a clickable link (assuming your terminal supports it) that will take you directly to the rule docs:

As of 0.15.17, you should already be able to use these names in ruff:ignore comments, on the preceding line as Micha showed or at end-of-line like noqa:

# ruff:ignore[builtin-variable-shadowing]
print = 1

print = 1  # ruff:ignore[builtin-variable-shadowing]

And I'm currently working on using them in all other selectors (#25887) and on an --add-ignore alias for --add-noqa that will add the suppression comments above automatically.

Again, that doesn't address a preference for codes over names in general, but the goal is definitely for the interface to be much more unified around the new names than is currently released in preview.

For rule T201, the output is very confusing

I like the old format just as much

@chirizxc

Thanks @chirizxc We should definitely improve this rule name 😆

Thanks @chirizxc We should definitely improve this rule name 😆

The same goes for this rule https://docs.astral.sh/ruff/rules/assert/

❯ ruff check
assert: Use of `assert` detected
...

Error codes have been around forever and ruff is making (yet another [1]) destructive change to the linting community. Our configs use the "E*" style selections and that seems to be "disregarded feature" (at least from what I can tell of the discussions)? The change is a huge negative and incredibly disruptive.

[1] A few versions ago the output was unnecessarily changed and move filenames to a separate line or something. I can't remember the exact details, but it was pretty annoying.

error codes are easier to remember, we can directly see from which tool it originates (F,E,PLW,PLE,I,...), they are shorter to type, shorter to remove with backslash when iterating over many rules due to new upstream changes, …

If you change the output in ruff, please give a output-format option to show the error numbers or at least prefix all human readable codes with the error codes.

Which uses even more horizontal space...

100% agree, i think its super annoying that i now need to open up the URL to the specific error to grab the error code to then add it manual to the document as an exception

You can use ruff: ignore[name] instead of noqa: code

That isnt working in my env. It only works inline but not for the whole document

You can use # ruff: file-ignore[unused-import, unused-function-argument] . See https://docs.astral.sh/ruff/linter/#file-level

Which uses even more horizontal space...

I understand that you dislike the change and I was not arguing against introducing an option to change the output. I only tried to explain that there are alternatives to opening the documentation only to get the code.

+1 in favor of opt in / bringing back error codes!

@MichaReiser

@MichaReiser hi 👋
Friendly ping on the importance of this feature.

Recent ruff update actually made it much worse, because when RUF is enabled with autofix it refactored lots of my code and configuration with me noticing it way too late.

Can we please make such destructive changes with a user consent? ruff can have a new error code for such things like IGN and place all such rules there, so people who need such feature can enable it. While it will stay disabled for people who want just useful RUF rules :)

Recent ruff update actually made it much worse, because when RUF is enabled with autofix it refactored lots of my code and configuration with me noticing it way too late.

We'll very likely introduce an opt-out to showing rule codes by default.

However, I consider it unlikely that we change the default of the new migration rules. Using human readable names is what we recommend. You can opt-out if you dislike this change. This will be a minor change for all users not using preview (alongside a heads up in the Changelog and a blog post).

ruff can have a new error code for such things like IGN and place all such rules there, so people who need such feature can enable it.

I don't think there's much benefit to this now, at least for preview users, because we now implemented all the rules. Moving the rules under another enabled-by-default category would only break your configuration again.

Add an option to opt out of human-readable names

As someone who opts in to everything with about 10 rules ignored and preview = true, I am not a huge fan of the change and I wish there would be an option to keep the old way going complete. VS Code Ruff extension now only does fixes with the human-readable names.

I disabled the three affecting me with this (RUF105, RUF106, RUF201), but I guess I will use the new style from now on. Eventually remove those rules from ignore.

Strong +1. This was a breaking change in terms of compatibility. E.g. I have custom tools that relied on the old format. At the very least there should be an option to return back to the old way of doing things.

Strong +1. This was a breaking change in terms of compatibility. E.g. I have custom tools that relied on the old format. At the very least there should be an option to return back to the old way of doing things.

My 2¢ are that tools should not be a factor in this discussion. The default output format is meant for human consumption, not for tools. Tools should probably be using one of the several formats offered by --output-format.

Tools should probably be using one of the several formats offered by --output-format

Agreed. --output-format can just be told to use the old codes-based format.

Add an option to opt out of human-readable names (#27160)

Thanks again everyone for the feedback! The next release will contain a new top-level option called output-prefer-rule-codes that will allow you to restore the non-preview behavior. That release should go out on Thursday.

@ntBre

Awesome, @ntBre ! Thanks!

Navigation Menu

Repository navigation

Option to opt in to showing error codes or show error codes in addition to rule names #26320

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Option to opt in to showing error codes or show error codes in addition to rule names #26320

Description

Activity

MichaReiser commented on Jun 24, 2026

sobolevn commented on Jun 24, 2026

MichaReiser commented on Jun 24, 2026

sobolevn commented on Jun 24, 2026

MichaReiser commented on Jun 24, 2026

MichaReiser commented on Jun 24, 2026

ntBre commented on Jun 24, 2026

chirizxc commented on Jun 26, 2026

MichaReiser commented on Jun 26, 2026

chirizxc commented on Jul 3, 2026

Sxderp commented on Jul 8, 2026

spaceone commented on Jul 9, 2026

3 remaining items

ThiefMaster commented on Jul 12, 2026

phifuh commented on Jul 12, 2026

MichaReiser commented on Jul 12, 2026

disouzam commented on Jul 13, 2026

sobolevn commented on Jul 20, 2026

MichaReiser commented on Jul 20, 2026

Tatsh commented on Jul 27, 2026

giampaolo commented on Jul 27, 2026

m000 commented on Jul 27, 2026

giampaolo commented on Jul 27, 2026

ntBre commented on Jul 28, 2026

disouzam commented on Jul 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions