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.
You could say that about anything, though. Why use punctuation and capitalization when typing forum comments? Its just syntax after all.
Black – Uncompromising Python code formatter
71–80 of 251 posts
Re: Black – Uncompromising Python code formatter
#72I 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.
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 removes a ton of deviations that don't matter, and desocializes the aesthetics.
This saves code reviewers time and stress and helps them focus on what actually matters in the code.
And it only has to save more time than it takes to run "pipenv run black" to be measurably worth it.
Re: Black – Uncompromising Python code formatter
#73Earlier quoted context omitted.
Are you sending unfortunate examples upstream? It's still beta, so it can be improved somewhat.
No, because I believe this is fundamentally unfixable. It's not a matter of changing this or that behavior, it's a matter of (apparent) formatting inconsistencies being important to convey intention and distinguish more important from less important bits. In the example I mentioned, I may sometimes choose to put a small dictionary initialization into a single line if it's just a detail, or may split it into multiple…
I have not used Black, but considering it so I am curious about these occasional situations where you want to override auto-formatting
Re: Black – Uncompromising Python code formatter
#74I've been using this for a couple of weeks and its a been really nice to remove the constant mental overhead of structuring code. it also makes you think about structuring functional blocks into more manageable, bite-sized chunks which is easier to understand. 10/10 would recommend
Re: Black – Uncompromising Python code formatter
#75I 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.
> 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.
I've never been able to wrap my head around people having strong opinions on style issues. I'll defer to whoever cares the most on the team and then just do that. When I look at the problems in code bases, rarely has "slightly inconsistent formatting" been at the top of the list.
Re: Black – Uncompromising Python code formatter
#76Re: Black – Uncompromising Python code formatter
#77Re: Black – Uncompromising Python code formatter
#78I 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.
> 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…
Re: Black – Uncompromising Python code formatter
#79Earlier 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.
You could say that about anything, though. Why use punctuation and capitalization when typing forum comments? Its just syntax after all.
Re: Black – Uncompromising Python code formatter
#80Against 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…
In this particular case, that may result in code that breaks with tradition. But I can't see a way to preserve the tradition without creating special or edge cases. For example, we can't follow the first option and get clean formatting with a function like zip. You'll have a train wreck of bad options about where to put the braces and how to place the comprehension's body in relation to the braces that enclose it. Versus, with Black's style, the answer is easy and straightforward, because you just do it the same way you would anywhere else:
zipped = zip(
{
apple.stem
for satchel in satchels
for apple in satchel
},
{
apple.core
for satchel in satchels
for apple in satchel
}
)
IMO, that's good, even if it isn't what we're all used to. Having a bunch of special cases just to match what someone might think is more aesthetically pleasing in specific situations is not a desirable feature in a set of autoformatting rules.