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

91–100 of 251 posts

Re: Black – Uncompromising Python code formatter

#91

Post by masklinn »

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.

> treating deviation as compiler errors.

That's not the case at all. The Go compiler treats an arbitrary few lint issues as compiler errors (e.g. unused imports), code which is not gofmt-formatted isn't a compiler error.

Re: Black – Uncompromising Python code formatter

#92

Post by camgunz »

emplynx wrote: post #46
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 use it with f-strings all day long...

Oh that's interesting. I looked up the Issue [1] and it looks like it was an upstream bug, but also if you're using that version of Python (which, of course, we are) you'll still have that problem. Thanks for chiming in, you're gonna make my life a lot better haha.

[1]: https://github.com/google/yapf/issues/342

Re: Black – Uncompromising Python code formatter

#93

Post by objektif »

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…

Thats how I code in production.

Re: Black – Uncompromising Python code formatter

#94

Post by PhilipTrauner »

Since I've started using black as a pre-commit hook and an editor extension, I have noticed that I tend to use inline-if expressions and lists comprehensions much more liberally, because I do not have to worry about formatting all the time. Begone temporary variables!

Re: Black – Uncompromising Python code formatter

#95

Post by firethief »

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.

That's a mostly invalid counter-objection. Technically true, but with context its usually recoverable.

Re: Black – Uncompromising Python code formatter

#97

Post by acdha »

roma1n wrote: post #10

How do you enforce the use of a formatter in a project -- pre-commit hook? pre-receive hook? both? And is there a convention to put a specific dotfile at the project root to hint at your IDE/editor that it should use a certain tool for automatic formatting?

We use pre-commit.com – configure your project with dotfiles for various tools so things like editor auto-format & lint, pre-commit, etc. can pick them up, and then have a Git pre-commit hook which is also run by your CI tool for consistency.

Here’s a reference:

https://github.com/LibraryOfCongress/coding-standards

The CI check can be pretty simple — for example: https://github.com/LibraryOfCongress/concordia/blob/2f813f18...

Re: Black – Uncompromising Python code formatter

#99

Post by weberc2 »

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

Sounds like you're using it wrong. The autoformatter is for the whole repo, not for individual contributors. The point is that the whole repo has the same style, so you should only ever get diffs on the lines that were changed or the first time you run the autoformatter on the repo (and then you shouldn't be making manual changes that will be hidden amid the autoformatter noise).

Re: Black – Uncompromising Python code formatter

#100

Post by mixmastamyk »

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.

In theory yes, but the grandparent just gave an example of where they don't like what it did to code. Could easily be someone else's.
Post reply on HN