Auto-formatting code with black - object now if you have a strong opinion

Yuya Nishihara yuya at tcha.org
Wed Dec 5 08:23:17 EST 2018


On Tue, 4 Dec 2018 10:06:24 -0500, Augie Fackler wrote:
> Those are...unfortunate. My bias, after years of using source-to-source formatters, is that I'd rather have machine-enforced known-stable formatting that's occasionally suboptimal (un-wrapping container literals is annoying and also a "feature" of clang-format) than have to think about doing my own formatting (especially wrapping). I know I wouldn't have had this position ~5 years ago, but it's remarkably liberating to not have to worry about formatting.
> 
> I think I have an idea for the imports case, but I'll hold off on doing anything until I feel like there's more consensus on if we should actually try black or not. I'm also open to ideas on how we could experiment with it in a contained way. Maybe we could try running it on only hgext/remotefilelog for a few weeks and see how people feel about it in those files? We'd still have to do some edits to check-code in order to make that work, but nothing too complicated...
> 
> As far as yapf goes, we use it at Google, and it's not as strong-willed as black, which cuts both ways. On the positive side, it will leave a container as spanning many lines as long as you leave a trailing comma after the last entry (that is, [foo,bar,] -> should be multiline, [foo, bar] -> should be single line), but on the negative last I checked it wasn't as deterministic, and depending on the formatting that went in it could produce different formatting on the way out. That means you're somewhat more likely to end up with spurious formatting diffs because you perturb some whitespace. black takes a much more draconian approach where for a given AST stream it wants to produce the same output file, with no concern given to the initial whitespace. I'd be happy to try out yapf too, if there's sufficient interest: I think black is better overall, but yapf would be better than continuing to manually format things.
> 
> So, options to move forward:
> 1) blacken everything (controversial for good reasons)
> 2) try black only on a subset
> 3) explore yapf
> 4) Give up and keep manually formatting files (I'd rather not do this, but I understand if it's where we end up)

My vote: 3 > 4 > 2 > 1

I'm not super enthusiastic about 100%-machine-forced formatting. I like
consistency level provided by e.g. astyle command. clang-format is pretty
good IMHO, but the black seems to sacrifice the code readability.


More information about the Mercurial-devel mailing list