Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Black – Uncompromising Python code formatter

github.com

Post reply on HN
Print view View original

161–170 of 251 posts

Re: Black – Uncompromising Python code formatter

#161

Post by zaphar »

Demiurge wrote: post #47
zaphar wrote: post #36

Earlier quoted context omitted.

While I agree that the formatting choice looks a little weird. The primary benefit of a formatter is that the formatting is always the same not. It's less important that it matches everyone's preferences and more important that it always formats the code the same way.

If most people dislike it on my team, we simply won't use it :(

It must be nice to work on a team where everyone agrees on the formatting. I don't think I've ever worked with a team where that was true. The exception being languages where the formatting was enforced by the language tooling itself. Those occasions no one even discussed it so I wouldn't exactly know if they agreed with it or not.

Re: Black – Uncompromising Python code formatter

#163

Post by rcfox »

TeMPOraL wrote: post #79
adossi wrote: post #61

Earlier quoted context omitted.

You could say that about anything, though. Why use punctuation and capitalization when typing forum comments? Its just syntax after all.

No, that's a completely invalid objection. Punctuation in natural languages isn't just aesthetic, it changes meaning.

Punctuation, or lack of it, can change the meaning in programming languages too.

https://medium.freecodecamp.org/codebyte-why-are-explicit-se...

Re: Black – Uncompromising Python code formatter

#164

Post by anoncake »

cjbprime wrote: post #35

I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it. Having a standard is more important than the standard being excellent.

> I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it.

I'm completely indifferent to autoformatters turning my coworkers' code from one perfectly readable format into another. The "problem" they solve is a ridiculous thing to worry about. Having a standard is not important, it's petty.

What I do dislike is having to fight the autoformatter because for some reason some teams use different settings. I dislike autoformatters turning code into something that is objectively harder to read -- sometimes it's not a matter of taste. Even when they work, I dislike even a second on something that only satisfies other peoples' pettiness. I also dislike git blame being useless because someone reformatted all the code for no good reason.

Re: Black – Uncompromising Python code formatter

#165

Post by franey »

AlexCoventry wrote: post #159
epistasis wrote: post #78

Earlier quoted context omitted.

Agree 100%, except for a minor quibble at the end. I've tried a few small projects with pipenv and black recently, and though I love black, I'm still struggling to accept pipenv as good. It's so slow so often, and I can't understand why.

Try poetry. https://johnfraney.ca/posts/2019/03/06/pipenv-poetry-benchma...

I've been meaning to update that post to mention that Poetry has been releasing fixes and improvements more frequently than Pipenv. Poetry is great for developing packages, too.

(Showing up in an HN thread is a neat little milestone for my blog and me. Thanks for sharing!)

Re: Black – Uncompromising Python code formatter

#166

Post by camel_Snake »

epistasis wrote: post #78
ben509 wrote: post #72

Earlier quoted context omitted.

> Having a standard is more important... Let me take a shot at why it's important. We spend years peering at code hunting for tiny, miniscule mistakes. Thus we're training ourselves, quite rigorously, to spot minor deviations. We're also irrational in the moment: our aesthetic sense is bothered by certain patterns, and our social sense wants to assign blame for this "wrongness" to individuals. An auto-formatter remov…

Agree 100%, except for a minor quibble at the end. I've tried a few small projects with pipenv and black recently, and though I love black, I'm still struggling to accept pipenv as good. It's so slow so often, and I can't understand why.

It's not you. There are plenty of people who dislike pipenv. Another commentor suggested poetry, which is what I favor when 'python3 -m venv .env' isn't appropriate.

Re: Black – Uncompromising Python code formatter

#167

Post by anoncake »

rcfox wrote: post #163
TeMPOraL wrote: post #79

Earlier quoted context omitted.

No, that's a completely invalid objection. Punctuation in natural languages isn't just aesthetic, it changes meaning.

Punctuation, or lack of it, can change the meaning in programming languages too. https://medium.freecodecamp.org/codebyte-why-are-explicit-se...

Yeah, but no one would remove punctuation from a program because they think it looks nicer.

> Javascript developers

Oh, of course.

Re: Black – Uncompromising Python code formatter

#168

Post by anoncake »

bunderbunder wrote: post #67
amelius wrote: post #44

Earlier quoted context omitted.

> Having a standard is more important than the standard being excellent. Neither is very important, though. It's just formatting and your code will run the same regardless.

They're not very important if you're the only developer on your team. If you're working with others, though, then it becomes very important. I don't think I'm being entirely hyperbolic when I say that inconsistent or poorly-chosen formatting rules are the death of 1,000 cuts for a team's productivity. There's a tiny but existent cost that's incurred every time formatting rules that aren't diff-stable result in a nois…

> There's a tiny but existent cost that's incurred every time formatting rules that aren't diff-stable result in a noisy code review that takes longer to read, or makes it harder for reviewers to discern the real changes from the formatting junk. There's a tiny but existent cost when excess delta makes it harder to gitblame.

Don't reformat code you didn't otherwise touch. That's just common sense. Common sense autoformatters lack.

> There's a tiny but existent cost when people have to stop and think about how to format their code manually.

I rarely think about how I format my code. When I do, it's because the code is hard to format in a readable way, in which case an autoformatter will produce garbage.

> Or when they have to stop and debate formatting.

"Doctor, it hurts when I do this."

> Or when they read someone else's code slightly more slowly because different formatting rules make it harder for them to skim it or rely on pattern recognition instead of careful reading to understand its structure.

Neglible. To the contrary, different formatting reminds you that you did not write this code and you should read it more carefully because you can't expect its creator to think the way you do.

Re: Black – Uncompromising Python code formatter

#169

Post by schemathings »

msluyter wrote: post #121

If you use PyCharm, you can use cmd-alt-L to autoformat a file (and also reorder/fix imports). By default, I believe it just uses the pep8 standard, which I find generally sufficient, but you can evidently integrate Black via: https://black.readthedocs.io/en/stable/editor_integration.ht...

FWIW gg=G formats in vim (whole doc), with lots of variations available .. more examples: https://stackoverflow.com/questions/506075/how-do-i-fix-the-...

Re: Black – Uncompromising Python code formatter

#170

Post by anoncake »

camgunz wrote: post #28

Against my better judgment I'll bite. I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings". Here's a small example: basket.add({ apple.stem for satchel in satchels for apple in satchel }) Black formats this as: basket.add( { apple.stem for satchel in satchels…

> I'd prefer to use yapf, but last I checked it still crashes on "f-strings".

There is a great autoformatter that does not have this issue. Using it guarantees that you'll never have to stick with an outdated version of a language because your autoformatter of choice hasn't been updated for the current one, or even worse, is not maintained anymore.

It's called "cat".

Post reply on HN