3 ms·

That doesn't really seem like a good reason. They remove all formatting control with an automated tool so it doesn't matter when (if, big if) an automated tool

That doesn't really seem like a good reason. They remove all formatting control with an automated tool so it doesn't matter when (if, big if) an automated tool later rewrites some of your source code formatted in a way you don't control?

Nzen 2y ago
Mu. Russ Cox quote indicates that the maintainers of goimports and gorename do not need to handle formatting at all (and hence, benefit). The go team put that wholly in the gofmt team's court. Otherwise, the go team would likely have to handle tickets about how the formatting of goimports and gorename differ over time for edge cases (if only by paying the social capital of ignoring the tickets).
- DangitBobby 2y ago
  That would fall under what I already assumed to be true, and also under an umbrella they specifically said it wasnt about > end debates among team members about program layout (Except in this case of course it's not "team members") I'm definitely not getting this interpretation from the quote.
striking 2y ago
It's more common than you think! Tools like https://github.com/facebook/jscodeshift https://github.com/facebook/jscodeshift, https://ts-morph.com/ https://ts-morph.com/, and https://ast-grep.github.io/ https://ast-grep.github.io/ are the ones I'm more familiar with (since my day-to-day is TypeScript). When I led the conversion of a decently-sized codebase from Flow-typed JS to TypeScript, I ensured that a code formatting tool that we were already using on pre-commit and CI called `prettier` was executed after each step. We took a git snapshot of each step of our automated conversion pipeline, and the diff was much clearer with `prettier` in place at each of those steps. We've since used codemods frequently to make huge changes to the codebase in an automatic, reproducible, iterable way. They're very comfortable, very fun, and (thanks to the use of a formatter on all code) rarely produce incomprehensible diffs.

Nzen 2y ago

Mu. Russ Cox quote indicates that the maintainers of goimports and gorename do not need to handle formatting at all (and hence, benefit). The go team put that wholly in the gofmt team's court. Otherwise, the go team would likely have to handle tickets about how the formatting of goimports and gorename differ over time for edge cases (if only by paying the social capital of ignoring the tickets).

DangitBobby 2y ago
That would fall under what I already assumed to be true, and also under an umbrella they specifically said it wasnt about > end debates among team members about program layout (Except in this case of course it's not "team members") I'm definitely not getting this interpretation from the quote.

striking 2y ago

It's more common than you think! Tools like https://github.com/facebook/jscodeshift https://github.com/facebook/jscodeshift, https://ts-morph.com/ https://ts-morph.com/, and https://ast-grep.github.io/ https://ast-grep.github.io/ are the ones I'm more familiar with (since my day-to-day is TypeScript). When I led the conversion of a decently-sized codebase from Flow-typed JS to TypeScript, I ensured that a code formatting tool that we were already using on pre-commit and CI called `prettier` was executed after each step. We took a git snapshot of each step of our automated conversion pipeline, and the diff was much clearer with `prettier` in place at each of those steps. We've since used codemods frequently to make huge changes to the codebase in an automatic, reproducible, iterable way. They're very comfortable, very fun, and (thanks to the use of a formatter on all code) rarely produce incomprehensible diffs.