I guess the line might feel fuzzy to some people, since nowadays many tools bundle both linting and formatting. And with modern IDE integrations, you might not even run them explicitly — the editor just does both automatically in one go.

Lately I've switched to the terms "check" and "fix" because more and more formatters (at least in my bubble of Python and Go) are incorporating fixes. So not just rearranging code and maybe adding a comma here and there.

many people use the prettier plugin for eslint, for example, so in that case they're one and the same!

Why build understanding when you could be pedantic?

> just going through and moving shit around whenever you save a file.

This only happens because the file doesn't already adhere to the rules it's implementing. These are normally highly configurable, and once your code complies to a standard, the tool prevents future code from pulling you away from that standard.

> And sometimes, they actually insert bugs - string formatting errors are my favorite example.

Do you have a concrete example?

> Sometimes I'll get a pull request with like 2 lines of change and 120 lines of some reformating tool.

Is your existing code formatting at least consistent?

> You think I accept that?

This is a social issue rather than a technical one. You can tell people in your development readme to use specific style rules, or even a project-wide precommit hook. If your own code is formatted with one of these tools, you can even (to my understanding) set up automated checks on GitHub's side.

But of course you are free to reject any PR you want.

You have it entirely backwards. Enforcing a consistent format is useful precisely because it avoids pointless git noise from different people changing formatting differently as they go.

Running random formatters on random subsets of your code is not a good idea. If you want code in a repo to be formatted a certain way, you need to have one set of settings and enforce it, and yeah, reject anything that just has spurious formatting changes that someone else has run.

> This is most noticeable in open source contributions. Sometimes I'll get a pull request with like 2 lines of change and 120 lines of some reformating tool.

This wouldn't happen nearly as much if you had a defined set of formatting rules plugged into CI instead of chaos

Formatters breaking code is not something that happens in all language ecosystems; I think it's mostly a C++ and occasionally JS issue, but for gofmt and many other formatters just don't break code. It's also not really that common anyways.

You can solve the Git noise issue by enforcing formatting in CI and keeping formatter configuration in repo. This is what most high quality open source projects will do. The purpose of this is not about "adhering to aesthetic ideologies", it's about not bothering people with the minutiae of yet another pointless set of formatting conventions. Most developers couldn't give a shit less where you think braces should go, or whether you like tabs or spaces, or whatever else, they care about more important things like data structures and writing more correct code. Having auto formatting enables them to effortlessly follow project norms without needing to, for every single repo they work in, carefully try to adhere to the documented formatting (which usually winds up being inconsistent eventually anyways, in projects without auto formatting, because humans are fallible.)

The reason why people submit code with a huge formatting diff is usually because your project didn't ship a formatter manifest but their editor is configured to format on save. That's because probably most of the projects people work on now do actually use some form of automatic formatting, be it clang-format, gofmt, prettier, black, etc. so it winds up being necessary to special case your project to not try to run a formatter. It's still a beginner's mistake to actually commit and PR a huge reformatting, but it definitely happens by accident to even experienced devs when working on projects that have weird manual formatting.

I’ve seen multiple repos with pre-hook and just CI running formatter on _modified_ code only. Those repos were the cleanest to date.

I'll sound off more on this.

Formatters also value consistency over clarity.

I break formatting all the time for the sake of clarity.

Sometimes my comments are paragraphs long with citations and things are carefully broken down with interstitial comments and references and then the formatter fucks it all up and the linter says "wah this oblivious pedant rule isn't followed"

The problem is it doesn't treat me like an adult And I'm not in this industry for dumb Nanny tools that scold me because they don't understand things

Avoiding that situation is what I like about formatters. As long as the language has an obvious standard like rust or go.

> Sometimes I'll get a pull request with like 2 lines of change and 120 lines of some reformating tool.

The reformatting tools should be CI-enforced so you'll only end up with sudden massive changes like this once when you start using auto-formatters.

Regardless, tell your teammates to separate out formatting changes vs logic changes into separate commits (preferably separate PRs). Since they're auto-formatters it wouldn't even be any additional work, just:

  git fetch origin
  git checkout origin/main
  git checkout -b formatting
  ./run_the_autoformatter.bash
  git commit -a -m "Ran the auto-formatter, which should have been enforced by the CI."
  git push -u origin formatting

What I do is make two separate PRs - one for the coding change, the other for reformatting only.

I’ve used this before, it helps when you format the entire repo and remove the one commit from the history https://docs.github.com/en/repositories/working-with-files/u...

formatting on git diffs is a concept which should be embraced.