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

81–90 of 251 posts

Re: Black – Uncompromising Python code formatter

#81

Post by alexhutcheson »

Feature request: Add a flag that allows you to specify which lines to format.

I'm an auto-formatting true believer, but I hate doing code reviews where the author has run a formatting tool that introduced diffs all over parts of the file that they didn't actually touch. It makes it really hard to review the actual change, and you have to worry about missing something.

With something like ClangFormat's '--lines' flag, you can configure the tool to only modify the lines that the author actually changed. This removes most of the pain that comes with adopting an auto-formatting tool, and your codebase will gradually converge to the fully auto-formatted state over time.

This also makes it easier for to introduce improvements to the formatting tool itself, because the improvements won't immediately force a bunch of diffs on code that was already "blessed" by the tool.

Re: Black – Uncompromising Python code formatter

#82

Post by abtinf »

hardwaregeek wrote: post #7

This is a case where I'm completely decided. Everybody should use an autoformatter. The minimal benefit you get from custom formatting is completely outweighed by the uniformity, the consistency and readability of autoformatted code.

I think a nontrivial portion of Go’s success can be attributed to having a standard format and treating deviation as compiler errors.

It is immensely valuable to be able to look at any Go code, whether in the toolchain, the standard library, or a random stackoverflow snippet, and not have to think about formatting at all.

Re: Black – Uncompromising Python code formatter

#83

Post by jrootabega »

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…

Your examples read like a poem

Re: Black – Uncompromising Python code formatter

#84

Post by andrewljohnson »

We recently started using a lot of auto-formatters across our Python/iOS/Android code, as the team has grown (there are 17 people touching code at the company now).

I like auto-formatting, because it makes PRs less stressful to commit, and makes review comments more focused on stuff that actually matters. How exactly the code gets formatted is not something I care much about, just that it happens consistently, and I don't have to think about it.

We use pre-commit with Black and other formatters, such that it formats the code, warns you stuff changed, prevents the commit, and makes you recommit with the formatting patch included.

Re: Black – Uncompromising Python code formatter

#85

Post by asdkhadsj »

tedmiston wrote: post #57
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 think that's why it self-describes as an opinionated formatter vs YAPF where one has very granular control. My understanding is that by using Black you're saying I choose to not express my opinions about formatting aesthetics and delegate that decision to Black instead.

I'm not a python person (for many years, at least), but I'd choose black for a completely different reason. By using Black, I'm choosing standardization over my whims.

Which, as a longtime Go dev and now Rust dev, I love formatters that are opinionated. I don't always love what Gofmt or Rustfmt do, but I definitely like consistency that the community has in code style.

So I don't care what Black thinks - I care what, hopefully, everyone uses. Though, I could see a situation where formatting can be altered and the project has a format config. Meaning that while code fmt differs between projects, it would be consistent among all devs working on X projects.

Re: Black – Uncompromising Python code formatter

#86

Post by gubbrora »

I initially used autopep8 and had set vscode to autoformat region on paste. When I changed to black I started getting error messages about region format not supported everytime I pasted.

As I mainly use other languages, with formatters with working region support, I went back to autopep8 so I could leave it format region enabled.

Re: Black – Uncompromising Python code formatter

#87

Post by goostavos »

infecto wrote: post #64

I have just started using it and love it. It sounds funny but while formatting is not always a deal breaker it still kills me for 1) readability and 2) the faith that when someone reads the code base later one they know I was not an idiot. I know 2 is kind of subjective but when I look at someone elses code and I see obvious mistakes against pep8 I start judging both the person and the code harshly. Perhaps unfair bu…

That's pretty lazy thinking, imho. "Person x doesn't care about their code because they didn't use the formatting I like"

Worrying about or judging code based on PEP8 is missing the forest for the trees[0]

[0] https://www.youtube.com/watch?v=wf-BqAjZb8M

Re: Black – Uncompromising Python code formatter

#88

Post by fwip »

abtinf wrote: post #82
hardwaregeek wrote: post #7

This is a case where I'm completely decided. Everybody should use an autoformatter. The minimal benefit you get from custom formatting is completely outweighed by the uniformity, the consistency and readability of autoformatted code.

I think a nontrivial portion of Go’s success can be attributed to having a standard format and treating deviation as compiler errors. It is immensely valuable to be able to look at any Go code, whether in the toolchain, the standard library, or a random stackoverflow snippet, and not have to think about formatting at all.

I think you're conflating two concepts a little bit - deviation from `gofmt` isn't a compiler error, but lots of things (like unused variables or imports) are. I think they're both great.

Re: Black – Uncompromising Python code formatter

#89

Post by bunderbunder »

plorkyeran wrote: post #66
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 don't universally love what autoformatters do to code my coworkers wrote. I've worked with plenty of people who manage to do fewer weird formatting things than what mediocre autoformatters do.

My sense is that configurable autoformatters are doomed to suck.

Because an autoformatter with 10 simple yes/no options has 1024 different ways those options can interact, and an autoformatter with 20 yes/no options has 1,048,576 different ways that they can interact. It's simply not possible to make sure that you're going to get reliably good results in the face of that kind of combinatorial explosion.

Versus, if there's only one way that it will format things, then the people designing the rules have a single stationary target that they can aim at.

Re: Black – Uncompromising Python code formatter

#90

Post by fwip »

andrewljohnson wrote: post #84

We recently started using a lot of auto-formatters across our Python/iOS/Android code, as the team has grown (there are 17 people touching code at the company now). I like auto-formatting, because it makes PRs less stressful to commit, and makes review comments more focused on stuff that actually matters. How exactly the code gets formatted is not something I care much about, just that it happens consistently, and I…

Because pre-commit can be tough to google sometimes, depending on your search history, here's the direct link: https://pre-commit.com/
Post reply on HN