In the C#/.NET world this is the standard and it works very well. It definitely increases productivity to not have to double check each and every instance of violating a lint error, as you can just have the fix applied to an entire project without having to worry to much.

> increases productivity to not have to double check each and every instance of violating a lint error,

At what cosmic speed should you be pumping out code for this to be a concern?

Also, in C#/.NET, where programmers predominantly use MSVS, which is an atrocious editor with MSBuild, which is an atrocious build system, both hampering productivity...

Also, plenty of linter errors are actual errors that need non-trivial fixing. So, I struggle to understand how that may be automatically fixed (at least in the context of Python). A trivial example: misspelled variable name -- how would the linter know if that's a typo, or that the programmer intended to declare this variable, but forgot to do that?

> Also, plenty of linter errors are actual errors that need non-trivial fixing.

These sound like they're not lints at all.

No, not really. It is perfectly possible to write unintentionally valid code, which would be caught by linter due to the author not following some convention.

Trivial and popular example of such code is assignment instead of comparison in the context of condition. Some languages allow for this to happen, but it's known as a possible mistake and so the conventions in such languages would discourage the use of assignment in the context of condition, even though it technically produces valid code.

It's very useful for multiple scenarios: 1. Learning new syntax. E.g. the new switch expressions are pretty neat and better than the old switch statements. Changing and learning how to write them is super easy thanks to this feature.

2. A code base with less then good practices is vastly easier to adjust to better standards than in python. I've done both and dotnet is mostly applying suggestions and then looking for more advanced problems which where not caught by automatic analysis. It's not perfect, but it reduces useless churn.

This also holds true for rider and vs with resharper.

And VS Code too with the analyzers that come with the sdk! (or numerous others that are available as extensions e.g. Roslynator)

As someone who worked on a similar tool (https://github.com/ssbr/refex/tree/main/refex/fix/fixers, I did a bunch of the work to prep this for open-sourcing, though I think all my contributions are hidden behind the "Google-internal" anonymization), having auto-applied or auto-appliable fixers like this is super useful.

They can be auto-applied by post-commit (e.g. a generic `git fixcommit` style command that runs all the relevant lint tools and fixes them in the working copy, letting you review before push), or applied during code review (automatic comments with a "click here to apply fix" interface), both of which are nice.

Plus the same underlying tooling can be used to write more complex one-off fixes that may be used for migrations or cleanups.

"black" for python has already done this for quite a while.

Even before that, some flake8 linting rules could automatically apply the fix, but not all of then.

You don't have to trust it - just commit your changes then run the linter and inspect the diff.

Ruby's Rubocop linter has had this for a long time and it works great. I thought this would be the case for most of the mainstream languages.

Adding to what other commenters said, ESLint also works like this.

However in an IDE setting it's not exactly "auto"; you have to click the light bulb and accept the fix (idk about VSCode, but in Neovim you can even get a preview of the diff [1]). This is what I'm working on a Fixit PR for right now.

[1] https://github.com/aznhe21/actions-preview.nvim