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

171–180 of 251 posts

Re: Black – Uncompromising Python code formatter

#171

Post by quacker »

p0cc wrote: post #5

I use black because it is idempotent. Google's yapf lacks this property. Edit: Previous discussion: https://news.ycombinator.com/item?id=17155048

Agreed. yapf has soo many config options, and I want to say some of those options are heuristics (like `SPLIT_PENALTY_AFTER_OPENING_BRACKET`) which can have some "unpredictable" side effects (at least to the eyes of a new user).

I prefer Black, which has minimal configuration. There's no debate to be had over details that don't matter much in the grand scheme of things. Yeah, maybe it doesn't always look _just_ how I'd like, but I get used it.

And while Black may not be 100% compatible with flake8 out of the box, they are aware of flake8 and document places where it may not be flake8-compatible.

Re: Black – Uncompromising Python code formatter

#172

Post by Mawr »

alexhutcheson wrote: post #81

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,…

>[...] 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. [...]

Teach them to commit properly:

1. Run an autoformatter on the file

2. Commit

3. Make desired changes

4. Commit again

The same principle applies to refactoring as well, you want to keep your commits 'atomic' aka containing a single unit of work. Autoformatting and changing the code are two separate units.

Re: Black – Uncompromising Python code formatter

#173

Post by andrewprock »

amelius wrote: post #143
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.

Why not let every user apply their own formatter? I bet that with a little work in the toolchain (git, editors, less), you can make this work.

Mostly because it's impossible to autoformat code well. You can only just barely get to "good enough".

Re: Black – Uncompromising Python code formatter

#174

Post by andrewprock »

anoncake wrote: post #167
rcfox wrote: post #163

Earlier quoted context omitted.

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.

Don't forget gofmt.

Re: Black – Uncompromising Python code formatter

#176

Post by AceJohnny2 »

ben509 wrote: post #72
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.

> 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…

I'm saving your and cjbprime's comments for future reference. You've both perfectly expressed the benefit and contextual benefit of code formatters.

Re: Black – Uncompromising Python code formatter

#177

Post by wwright »

owenmarshall wrote: post #128
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.

> no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code It always strikes me as strange that we spend our own effort and time on systems that mandate code style when my unambiguously correct style and my coworkers obviously incorrect style both end up converted to the same AST for any useful work. Why isn't style an entirely local choice, with a hi…

One term for this, I believe, is “structural editors.”

Re: Black – Uncompromising Python code formatter

#178

Post by grinchygrinch »

pletnes wrote: post #112

How do people use autoformatters in CI pipelines? I dislike the fact that precommit hooks have to be set up for each git clone. Is there a better way?

At my previous job, "Formatting" task was the first thing pipeline did. It was really simple - it ran the same "make format" target you could run locally, except it was configured in a way to fail if running "git diff" afterwards resulted in any changes when running on the build server (git diff -s --exit-code). Of course, when this failed, none of the other tasks in a pipeline ran so it forced you to format your code correctly if you wanted to see build results. You could just commit the next commit with "formatting" message but the idea was to just change the history since commiting was happening on dev branches - only when everything in the pipeline passed things could be merged on stable branches.

Re: Black – Uncompromising Python code formatter

#179

Post by meowface »

fjp wrote: post #138
asdkhadsj wrote: post #85

Earlier quoted context omitted.

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…

Our test pipeline fails any Python service trying to deploy if the black style check fails. I was initially grumpy about my org adopting black because I preferred single quotes, but the level of standardization is a huge win in my book. I never even think about my code style anymore, I just write it and then run black.

I've always been a double-quoter, in contrast to most Python devs I know/work with. After we standardized on black, I got some satisfaction seeing all of my coworkers bend to my will (/s).

Re: Black – Uncompromising Python code formatter

#180

Post by detaro »

meowface wrote: post #179
fjp wrote: post #138

Earlier quoted context omitted.

Our test pipeline fails any Python service trying to deploy if the black style check fails. I was initially grumpy about my org adopting black because I preferred single quotes, but the level of standardization is a huge win in my book. I never even think about my code style anymore, I just write it and then run black.

I've always been a double-quoter, in contrast to most Python devs I know/work with. After we standardized on black, I got some satisfaction seeing all of my coworkers bend to my will (/s).

How narrow those two choices are! The correct answer is obviously to use single-quotes for keys and key-like cases and double-quotes for values. Make formatters impossible to write! (last sentence very /s, but that style actually exists)
Post reply on HN