4 ms·

This still leads to frustrating behavior, where changing one line of a file might end up reformatting all of it (and this often obscures the actual change itsel

This still leads to frustrating behavior, where changing one line of a file might end up reformatting all of it (and this often obscures the actual change itself).

klodolph 5y ago
Tools like git-clang-format only reformat the code you’ve changed, not the entire file. A lot of formatting tools work this way (certainly not all).
jabo 5y ago
There’s an eslint plugin to run only on staged changes: https://news.ycombinator.com/item?id=27643526 https://news.ycombinator.com/item?id=27643526
- foreigner 5y ago
  That looks perfect.
  - onion2k 5y ago
    There's also the 'lint-staged' NPM package if you want to do pretty much anything only on staged files.
    - morelisp 5y ago
      I can't remember if this package specifically was one of the ones we tried (it was 3-4 different packages in the JS ecosystem), but anything that pretends files and not changes are the units of staging will cause problems for advanced git workflows.
cratermoon 5y ago
At one job I pushed back against a drive to introduce a pre-commit "format to standard" hook. Aside from the fact that nobody was really advocating for it other than one programmer who had, shall we say, a certain outlook, I have never wanted to see a commit that had both the relevant change and formatting fixes. While the "reformat lines that have changed" kind of works, you can end up with code that is half one style and half another, which is worse for comprehension than having it all one style, even if that style is a bad one. This wasn't Python, so at least we didn't have to worry that an automatic reformat could literally change the behavior of an entire block. There are still edge cases in most languages, around control structures, i.e. the infamous braceless "if". I think the implementers of the Go language got it right: there's one style, for everyone. Like it or hate it, there's no Holy War over it.

This still leads to frustrating behavior, where changing one line of a file might end up reformatting all of it (and this often obscures the actual change itself).

klodolph 5y ago

Tools like git-clang-format only reformat the code you’ve changed, not the entire file. A lot of formatting tools work this way (certainly not all).

jabo 5y ago

There’s an eslint plugin to run only on staged changes: https://news.ycombinator.com/item?id=27643526 https://news.ycombinator.com/item?id=27643526

foreigner 5y ago
That looks perfect.
- onion2k 5y ago
  There's also the 'lint-staged' NPM package if you want to do pretty much anything only on staged files.
  - morelisp 5y ago
    I can't remember if this package specifically was one of the ones we tried (it was 3-4 different packages in the JS ecosystem), but anything that pretends files and not changes are the units of staging will cause problems for advanced git workflows.

cratermoon 5y ago

At one job I pushed back against a drive to introduce a pre-commit "format to standard" hook. Aside from the fact that nobody was really advocating for it other than one programmer who had, shall we say, a certain outlook, I have never wanted to see a commit that had both the relevant change and formatting fixes. While the "reformat lines that have changed" kind of works, you can end up with code that is half one style and half another, which is worse for comprehension than having it all one style, even if that style is a bad one. This wasn't Python, so at least we didn't have to worry that an automatic reformat could literally change the behavior of an entire block. There are still edge cases in most languages, around control structures, i.e. the infamous braceless "if". I think the implementers of the Go language got it right: there's one style, for everyone. Like it or hate it, there's no Holy War over it.