3 ms·

It’s been a while since I’ve given black a shot, but I recall getting some really gnarly/ugly line wraps out of it and thinking it made the code less readable.

It’s been a while since I’ve given black a shot, but I recall getting some really gnarly/ugly line wraps out of it and thinking it made the code less readable. I liked the idea but not the subjective style choices the devs made

Kwpolska 4y ago
Black defaults to a line length of 88. While it is slightly larger than the old PEP8 standard of 79, and while it was chosen the intention of avoiding some ugly line wraps, it is still quite small and still leads to ugliness. Try raising the limit to a more reasonable 100-120 and see if it helps.
urxvtcd 4y ago
The way I think about it is that if black's output looks weird, you should probably restructure your code. It's not _always_ true, but often enough it means the code can be made simpler, some values created in flight can be given names, and so on.
- ttyprintk 4y ago
  Not saying there’s harm in realizing this, but the weirdest formatting choices in black seem to arrive deep in numerical formulae, where formatting actually makes differences in clarity. Under our typesetting-perfectionist overlords, our only recourse is to grow variable names so that the formulae make sense. And this defeats trying to reuse variable names from publication, so that a more-international audience can follow ‘ss’ rather than sum_of_squared_residuals_dude. Julia promotes this as a war cry over Python.
LtWorf 4y ago
I mostly don't like how removing a parameter to a function can make it become 1 line, and then in the diff I have no idea of what has happened. In reviews I always ask that there must be a separate formatting commit, at the end. Also, because our builds fail if the code is not formatted, that means constant reformatting and moving around of commits. In the end the time wasted to start the container to run black (if you use the distribution one, every version formats differently), to run black (which is terribly slow), and juggle the commits around is hardly worth it. However I believe from a management perspective it gets rid of discussions about style in the reviews, so it looks like time is being saved because now the developers waste it each on their own in silence, without communicating.
- ttyprintk 4y ago
  All your points are right in what I’d say is the most common ambient professional environment. We had an internal debate about how to gauge code quality. One camp only allowed the combination of black format plus coverage. To play devils advocate, I said that the number of asserts removed or added per merge request.

Kwpolska 4y ago

Black defaults to a line length of 88. While it is slightly larger than the old PEP8 standard of 79, and while it was chosen the intention of avoiding some ugly line wraps, it is still quite small and still leads to ugliness. Try raising the limit to a more reasonable 100-120 and see if it helps.

urxvtcd 4y ago

The way I think about it is that if black's output looks weird, you should probably restructure your code. It's not _always_ true, but often enough it means the code can be made simpler, some values created in flight can be given names, and so on.

ttyprintk 4y ago
Not saying there’s harm in realizing this, but the weirdest formatting choices in black seem to arrive deep in numerical formulae, where formatting actually makes differences in clarity. Under our typesetting-perfectionist overlords, our only recourse is to grow variable names so that the formulae make sense. And this defeats trying to reuse variable names from publication, so that a more-international audience can follow ‘ss’ rather than sum_of_squared_residuals_dude. Julia promotes this as a war cry over Python.

LtWorf 4y ago

I mostly don't like how removing a parameter to a function can make it become 1 line, and then in the diff I have no idea of what has happened. In reviews I always ask that there must be a separate formatting commit, at the end. Also, because our builds fail if the code is not formatted, that means constant reformatting and moving around of commits. In the end the time wasted to start the container to run black (if you use the distribution one, every version formats differently), to run black (which is terribly slow), and juggle the commits around is hardly worth it. However I believe from a management perspective it gets rid of discussions about style in the reviews, so it looks like time is being saved because now the developers waste it each on their own in silence, without communicating.

ttyprintk 4y ago
All your points are right in what I’d say is the most common ambient professional environment. We had an internal debate about how to gauge code quality. One camp only allowed the combination of black format plus coverage. To play devils advocate, I said that the number of asserts removed or added per merge request.