Naive question, but why is everybody so aggravated by formatting discussions? It seems to be a widespread opinion that these discussions are just 1) pointless and 2) difficult and time consuming.
My personal experience is that 1) in many cases you do benefit from taking a moment, going through your code and thinking about presentation. And 2) I find it not at all difficult to settle. A change either doesn't matter, then you just don't discuss it at all, or it is important, then you quickly agree on the best solution. (In the worst case, "best" means what the project lead finds prettier.) If you don't have a social mechanism to agree on something as basic as coding style, then your team probably has bigger problems.
I actually find robo-formated code annoying to read: Go code from a bloody beginner who doesn't know what they are doing looks exactly like carefully tended for, highly thought-out code. And in autoformatted Python, you for example cannot make formulas clearer by removing spaces around operators with higher precidence. Parentheses placement is dicated by how long words are and not by what logically belongs together, etc..
I think it's more that formatting discussion is _easy_: if you get a merge request, you can start adding comments like “this should be indented differently” or “wrap this here” and spend a lot of time “reviewing” the request without noticing that you missed an error in the logic because you were focused on the most visibly upsetting problem.
Using an automatic formatter also can help reduce diff noise, which is something I've noticed on more active projects. Using Black drives close to zero the amount of time I spend confirming that someone didn't actually change functionality along with formatting. There are other ways to get this, of course, but it's so easy just to enable Black and never spend your time on it again.
> Parentheses placement is dicated by how long words are and not by what logically belongs together, etc..
This is actually a bit more subtle: Black will remove parentheses when they don't have any effect (e.g. `(32)` will become `3 2` because it covers the entire expression) but if you use them for only a subset of the expression they'll be preserved (e.g. `(1(32))` becomes `1 * (3 * 2)`.
They are also huge timesinks, people spend less time sometimes deciding which framework or language or cloud provider to use and which country to register their company in, than spending hours and hours on how some SICK ANIMAL forgot a trailing comma somewhere, or bikeshedding how many spaces to indent with, and who uses an ultrawide monitor and wants wide columns (but then again someone turns theirs into portrait mode, and wants narrow columns), etc. Gobs and gobs of time, totally disproportionate to the issue at hand!
Yes, black sometimes produces fugly code, but at least the bikeshedding can fucking stop. There are bugs to fix, for chrissake. Yes, some people are not thoughtful enough to format their code like a piece of poetry, so what? Should everyone take Typography 101?
There is also a huge cohort of programmers who, when doing reviews and finding nothing to nitpick, resort to criticizing, in great detail, the code formatting of pull requests. They fell they MUST leave some critique or else their review is incomplete and their peepee is small. I find it hugely enjoyable that a tool like black can deprive them of the joy of belittling someone else for microscopically minor things and concentrate on, say, the actual merit of a change.
Like you, I'm quite fascinated by the apparent massive frustration and time sink that is apparently happening due to formatting discussions. Been working nearly 25 years in software at all levels, rarely using auto-formatted code, literally can't remember having one of these discussions. If anything I might even say I wish people cared a little more.
I do quite often artisanally craft formatting of specific code sections to highlight the intent of the algorithm or design. I assume black would merrily destroy all my hard work.
My personal experience is that 1) in many cases you do benefit from taking a moment, going through your code and thinking about presentation. And 2) I find it not at all difficult to settle. A change either doesn't matter, then you just don't discuss it at all, or it is important, then you quickly agree on the best solution. (In the worst case, "best" means what the project lead finds prettier.) If you don't have a social mechanism to agree on something as basic as coding style, then your team probably has bigger problems.
I actually find robo-formated code annoying to read: Go code from a bloody beginner who doesn't know what they are doing looks exactly like carefully tended for, highly thought-out code. And in autoformatted Python, you for example cannot make formulas clearer by removing spaces around operators with higher precidence. Parentheses placement is dicated by how long words are and not by what logically belongs together, etc..