> They want every codemonkey to be easily replaceable.
Code monkeys at Google are very expensive to replace. I'm sure Google would change that if they could, but nobody knows how. Code formatters are definitely not part of any stratagem to accomplish that goal. On the contrary, they want those monkeys spending their time producing value, not arguing over where to put the closing brace.
As long as you never work with anyone who disagrees with your style, or whose style you disagree with, an opinionated auto-formatter is not that useful. For the rest of us, it helps a lot. I remember early in my career before Google settled on clang-format, gofmt, etc., how every fourth person had a different opinion on how to indent this or that thing, and how occasionally it came up in code reviews. Or teams had their own team-specific style, so if you needed to fix something in someone else's code you had to break all your habits . . . god, it was horrible. How did we live like that.
Now I just run the code fix program before sending for review, and the only points to discuss are naming and software design, not the placement of spaces and newlines. I'm still so thankful for it even half a decade after these concepts became widespread at the company. Fates bless the people who work on code formatters.
> As long as you never work with anyone who disagrees with your style
> [...] and the only points to discuss are naming and software design,not the placement of spaces and newlines
lol. In my 15 years working with different people in different companies
I think I never had a serious argument about code formatting or a
serious discussion about placement of spaces and newlines (at most small
talk about those issues on coffee & cigarette breaks).
Once you are used to jump between different projects and languages you
just accept to use the style which is given.
Code monkeys at Google are very expensive to replace. I'm sure Google would change that if they could, but nobody knows how. Code formatters are definitely not part of any stratagem to accomplish that goal. On the contrary, they want those monkeys spending their time producing value, not arguing over where to put the closing brace.
As long as you never work with anyone who disagrees with your style, or whose style you disagree with, an opinionated auto-formatter is not that useful. For the rest of us, it helps a lot. I remember early in my career before Google settled on clang-format, gofmt, etc., how every fourth person had a different opinion on how to indent this or that thing, and how occasionally it came up in code reviews. Or teams had their own team-specific style, so if you needed to fix something in someone else's code you had to break all your habits . . . god, it was horrible. How did we live like that.
Now I just run the code fix program before sending for review, and the only points to discuss are naming and software design, not the placement of spaces and newlines. I'm still so thankful for it even half a decade after these concepts became widespread at the company. Fates bless the people who work on code formatters.