Hacker News Reader

Comment by Groxx | Hacker News Reader

Black has been around a while and has pretty widespread use: https://pypi.org/project/black/

Black is opinionated, but you just run it, accept the opinions, and never think about formatting after that. No debates over how to format a code block; focus on the actual logic being implemented.

yup, after i embraced black, i can't go back (no pun intended) to not using it. it makes reading code so much easier.

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

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.

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.

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.

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.

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.

Reply on news.ycombinator.com