It doesn't really put an end to them, it just turns them from N×N arguments between each pair of programmers to N×1 where everyone argues with me, the formatter maintainer. But, yes, that's a significant performance win (for everyone except me...). :)

I hear the author of Black (an opinionated Python formatter) was at a conference and gave a presentation that when something like this:

> I'm the author of Black. Questions?

Questions, of course, filled up the entire rest of the time slot.

From my perspective at least, you've always handled it with grace. Thanks for your work Bob.

You're welcome! :)

Every time I use one of these it ends up doing ridiculous things to the formatting, like splitting what should really be 1 line over 4 or 5. Which completely destroys whole-file readability/scanability. Does nobody else find it really hard to read codebases subject to these formatters?

The formatter that set the expectation of standard formatting was that for Go (gofmt), which applies a very light touch: it never removes newlines and rarely inserts them, so you still have latitude to arrange the code in a way that respects its meaning.

By contrast, the Java formatter we use at Google is an example of the totalitarian instincts unleashed by this new technology: it insists on reflowing everything, including the contents of comments so that they always use the full 100 columns. Madness.

There are always corner cases. For example, clang-format at $day_job doesn't understand semantically that I want my 4x4 matrix constant to be formatted as 4 rows with 4 numbers each; putting all 16 numbers in a single long array will get a lower score.

But as a whole, I found it easier to navigate the monolithic code base when most of it has been auto-formatted, exceptions aside. When applying a formatter to existing code, I usually do that in a separate commit and then follow it with any hand-rewritten lines afterwards (in case either the formatter or my changes afterwards accidentally regress something).

And once the formatter is enabled by default, it's usually easy enough to come up with a set of smaller statements that auto-format well to replace a longer statement that auto-formats poorly.

> For example, clang-format at $day_job doesn't understand semantically that I want my 4x4 matrix constant to be formatted as 4 rows with 4 numbers each

Comments can be a low-key forced line break:

    int matrix[16] = {
        0x0, 0x1, 0x2, 0x3, //
        0x4, 0x5, 0x6, 0x7, //
        0x8, 0x9, 0xA, 0xB, //
        0xC, 0xD, 0xE, 0xF, //
    };

Usually in cases like these I prefer to add the magic “formatter off” comment around the block: it’s self-documenting.

Don't just blindly run a formatter.

I've developed a habit of refactoring long lines early (e.g. breaking large expressions and assigning to intermediary variables) to prevent the formatter from adding hard-to-read mid-expression line breaks

Interesting.. not having to worry about where to break long lines and letting the formatter (in my case Prettier) figure it all out for me has been one of the most wonderful things in recent memory that has happened to my programming experience. I can just write awful looking code at the speed of thought and know it will turn out fine when I hit save.

Having to switch back to a non-opinionated non-line-breaking formatter like golang's makes me very sad.

Prettier outputs fairly decent formatting for code that is already reasonable to begin with. It's not so great when you have things like template strings with large expressions in the interpolation slots.

This is basically the approach I take, write towards the standards of the auto formatter as much as possible and it'll usually handle the rest.

It depends for me on the formatter. For me, blank lines are often part of how I express meaning. If the formatter is good at respecting my chosen line breaks, fantastic. If not, it's pistols at dawn.

I didn't really understand this until I started using golang. Now I don't want to go back to other languages and have to deal with varying syntaxes and manually running a formatter.

What's a language that lacks such a facility? ClangFormat covers C/C++/Java/JavaScript/Objective-C/Protobuf/C#. gofmt obviously can do Go. buildifier will rewrite your Bazel BUILD files.

Those aren't highly opionated default formatters though. The JavaScript community seems to have settled on Prettier as the go-to formatter, but not everyone uses it, and even Prettier had to add a bunch of options for certain things that will always be highly personal. Stuff like trailing commas, tabs vs spaces (and how many spaces‽), line lengths, and semicolons.

Well, one part of trailing commas in Prettier is that different versions of JavaScript support them in different places. With go fmt, the formatter is updated in lockstep with the language.

ruby

ruby has rubocop, although it is more basic.

> It puts an end to useless style arguments.

I don't like auto code formatting in my workflow and I don't like "easy"-syntax languages like Go. I see it is of value for big treadmill-code-machines like google. They want every codemonkey to be easily replaceable.

But for me code is also art and fun. I align my assignments and statements and I use different code-formattings according to the situation.

If I do all right I only write the code once but read it again and again for years. So I like to spend some time to format my code nicely, whatever that means :-)

Writing a code formatter is a fun challenge and sometimes its useful to have a good formatter but please not in my day-to-day job.

> 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.

oh, I have. Full on per-project style guides, determined in multiple core team meetings at kick-off.

And these people were excellent engineers...or at least they were when they weren't focused on minutiae.

Even with automatic code formatters, I've gotten into style discussions or been witness to them. At Google! In code review!

> They want every codemonkey to be easily replaceable.

Most folk/bosses who are risk averse actually want their codemonkeys to be easily replaceable (although admittedly, they might not realise it!). Nobody likes/wants a system with a single-point of failure.

If I'm working for a client, and get hit by a bus tomorrow, it is rather reassuring for the client if they know the work they've paid for so far can be fairly easily picked up and completed/maintained by another hire.

I deliberately make it part of my strategy to bring a client's attention to this kinda stuff, in an ongoing fashion. It means I can happily spend time on e.g. documentation and/or other technical debt, because my client understands the values of these things.

My actions to make myself (more) replaceable lowers my client's risks. (A good client understands this, and might acknowledge and support such efforts with fatter pay checks: someone who helps lower their risks can be a particularly valuable asset)

I guess it depends on one's attitude and understanding towards 'being replaceable', and how one pitches that understanding.

> Most folk/bosses who are risk averse actually want their codemonkeys to be easily replaceable

Absolutely, everything else wouldn't be very smart. Maybe my comment came off a bit more negative than I intended to.

I don't blame google if this mindset is reflected in their tools but I wouldn't like to have to work with that.

You can dislike auto code formatting without disparaging people.

??

You mean the word "codemonkey"? That was meant from the employers point of view. I'm a codemonkey myself...

I’m not a 1980s network censor chasing after “bad words” here. You painted a nasty picture of a company and its relationship with its employees. You can express yourself without attacks.

I don't see it that way. I think I just painted a picture of reality. I didn't even mean to say this behavior is bad.

Except for when they make the code harder to read, as black does with a decent chunk of pandas idioms.