5 ms·

It looks like the interesting feature of their tool Fixit 2 is that its lint rules know how to auto-apply themselves. I'm fine with an auto code formatter, an a

by driggs 3y ago

It looks like the interesting feature of their tool Fixit 2 is that its lint rules know how to auto-apply themselves. I'm fine with an auto code formatter, an auto import organizer, but not sure how much I trust a linter to auto-apply "fixes".

n00j 3y ago
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.
- crabbone 3y ago
  > 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?
  - insanitybit 3y ago
    > Also, plenty of linter errors are actual errors that need non-trivial fixing. These sound like they're not lints at all.
    - crabbone 3y ago
      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.
  - HdS84 3y ago
    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.
    - neonsunset 3y ago
      And VS Code too with the analyzers that come with the sdk! (or numerous others that are available as extensions e.g. Roslynator)
IshKebab 3y ago
You don't have to trust it - just commit your changes then run the linter and inspect the diff.
joshuamorton 3y ago
As someone who worked on a similar tool (https://github.com/ssbr/refex/tree/main/refex/fix/fixers 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.
Izkata 3y ago
"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.
theonething 3y ago
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.
llwu 3y ago
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 https://github.com/aznhe21/actions-preview.nvim

by driggs 3y ago

n00j 3y ago

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.

crabbone 3y ago
> 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?
- insanitybit 3y ago
  > Also, plenty of linter errors are actual errors that need non-trivial fixing. These sound like they're not lints at all.
  - crabbone 3y ago
    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.
- HdS84 3y ago
  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.
  - neonsunset 3y ago
    And VS Code too with the analyzers that come with the sdk! (or numerous others that are available as extensions e.g. Roslynator)

IshKebab 3y ago

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

joshuamorton 3y ago

As someone who worked on a similar tool (https://github.com/ssbr/refex/tree/main/refex/fix/fixers 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.

Izkata 3y ago

"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.

theonething 3y ago

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.

llwu 3y ago

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 https://github.com/aznhe21/actions-preview.nvim