1) A lot more code isn't read in vim or emacs nowadays. We don't have the equivalent of indent on the github web ui
2) Everyone and their mother is doing code reviews now, and a lot of code reviews get (very visibly) bogged down by style disputes.
3) indent and his modern friends (eg clang-format) generally only answer trivial whitespace questions, and not even things like method capitalization. gofmt is the obvious extension of indent.
Whether it's called indent, gofmt or Visual Source Formatter 2051 doesn't really change its availability. Nor does it really matter a lot how much of the source is munged -- every forced change is probably annoying to someone.
The main issue for me is that your code reviwer isn't looking at the code from my company. So why should I give a damn what they think about how spaces around the parens of a function call should look like in the code I'm editing?
I'm not convinced that this should leave the bounds of a project. Within that, sure! Let's put a .rustformat right next to .gitignore, and whatever your source discombobulation utility is called just takes its hint from there. Certainly nothing wrong with a language having a good indenter, doc tool and linter in the core distribution. But one language, one style, one tab width!?!
This is especially annoying when you've got a pretty unified style across all other algol-/C-ish languages, yet can't keep this in your newest one. For the sole reason of pleasing some community that'll never see one line of your code.
> This is especially annoying when you've got a pretty unified style across all other algol-/C-ish languages, yet can't keep this in your newest one. For the sole reason of pleasing some community that'll never see one line of your code.
It's rarely a good idea to reproduce the same patterns in two different languages (except for things that are common anyway, like indentation etc.).
And the main argument for a language-global code style is that you don't need to teach new commers (to your company/project) which code style you follow, you don't need to have long discussions about whether the article #36 is being respected in that last commit, if the code style version you had is up to date, etc.
One great example: Python and PEP8. It's the standard, everybody accepted it. That means that all libs use it AND (almost) all companies use it internally, which makes friction between different modules from different sources minimal.
That depends on your purpose and the problem you are trying to solve. If the problem is style bikeshedding, that can easily be solved through autoformatting and configurations for the standard for that project, company, etc. Write however you want, run it through the auto-formatter with the right config before commit (or add it to commit hooks). Problem solved.
If you want to solve the problem that people are writing in different styles and there should be one true style for a language, why? You're bound to get something wrong in your style initially, and it will be annoying from then on, and hard to change. It actually seems the antithesis to how Rust was developed, which was to keep trying things to see what worked.
Indeed, I am missing said point. Version control snafus aren't really an issue outside of my project, so it all comes to the endless repetition of "bikeshedding".
indent(1) is not idempotent, at least not in the configuration I tested, which makes it practically useless as an editor save hook or an SCM pre-commit hook.
Of all the C pretty-printers I tried (about a year ago), clang-format came closest but none were idempotent on the codebase I threw at it.
go fmt is idempotent, which means I use it in an editor save hook. I got used to the convenience, so now I miss an automatic formatter when writing other languages.
