Black however could fall into this category of worse than no formatter. On my team we have a strong style guide with a lot of well-reasoned, detailed, and consistent rules. One of the main differences to other style guides is that we design our style to make review easier. One of the primary ways of doing this is minimising diff noise.
While Black's vision is to reduce diff noise and design for easier review through a consistent style, it creates more diff noise and has a less consistent style than our style guide, and so we've had many discussions internally about whether it's right for us.
I have no doubt that Black is better than weak/no style guide, and for open source projects the automation it brings would absolutely be the right choice. I just wish it was better at what it sets out to do.
Edit: to address some of the questions raised:
- Yes Black does save time over code review picking on style details, but we already have automated linters for most things we'd raise about style anyway, which negates some of the time saving.
- The easiest example of where Black differs from our style guide and falls down on its promises is formatting lists/function calls/definitions.
For example:
foo = [bar, bar]
When reaching the line length limit, we will turn this into: foo = [
bar,
baz,
quux,
]
However Black will format this first as: foo = [
bar, baz, quux
]
Only when it goes on a few more characters does it then format into the way we'd go straight to. This means that there's more diff noise more of the time, and when reading code there are 3 forms of this construction that one must be aware of, rather than the 2 forms that we have, meaning the code is less consistently formatted.This is picky, yes, but the point of Black is to be picky, and in a team where we can have a very good shared understanding of a style, and where we do already have that style, Black is much less convincing.