4 ms·
A bad formatter is worse than no formatter, and unfortunately YAPF proves this out in my experience, being unstable, inconsistent, and tricky to configure. Bl
by danpalmer 7y ago
A bad formatter is worse than no formatter, and unfortunately YAPF proves this out in my experience, being unstable, inconsistent, and tricky to configure.
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.
- jsmeaton 7y agoHave you got any specific examples of different rules/styles? Have you brought any of them up on the issue tracker? I’m a very big fan of black, and had disliked a few choices. But it’s saved our team literally dozens of hours of nit picking and style fixes. It’s so good to never have to critique style and just focus on function.
- whitehouse3 7y agoOpening an issue on Black for anything but a true bug is chasing after the wind.
- yhoiseth 7y agoHow, specifically, do you minimise diff noise? I can imagine a couple of ways: - Split to as many lines as possible in order to avoid suddenly going from one line to many lines and vice versa when a line crosses a specified line length - Add trailing commas wherever possible
- 4140tm 7y agoI have hated every single formatter I've tried, other than Black. It seems to be the only one that's not just trying to put style into PEP8 compliance, but also keep it readable and maintainable. I'm also curious about the issues you've had with it.
- jp_sc 7y agoThe outout of Black is PEP8 compliant, just not what flake8 think PEP8 mandates.
- 4140tm 7y agoWeird. I also use flake8 and the only mismatch between the two has been the default line length of black, which I changed to 79. All is good now.
- ForHackernews 7y agoI hate black so much. I know it's somewhat irrational, but it's incredibly ugly and violates established usage in most Python projects.
- weberc2 7y agoAny formatter will violate established usage in most Python projects. I find black at least makes your code readable, compared with pprint-esque styles.
- cerberusss 7y ago> and so we've had many discussions internally about whether it's right for us Many discussions? I've never been on a project where code style required anything more than 10 minutes. The tech lead would ask: "everybody okay with the defaults of this linter/editor/whatever" and we'd reply "sure". How much time did those many discussions take, and what were the reasons you needed to put in that effort?
- weberc2 7y agoThis is a strange comment. It sounds like you’re using black wrong. First of all, when you pick Black, you throw away your own style guide (at least where black is concerned; keep the bits about function naming, etc). Secondly, you should only have one noisy commit, that being the very first commit in which you integrate Black. Thereafter, Black runs before code is committed so all code in code review is already formatted. Yes, if you already have comprehensive style linters and a team that agrees on style, you won’t see as much benefit, but you won’t need to maintain your custom linters or style guide or have all of these conversations about style (you also don’t need to iterate with a linter).