221–230 of 251 posts
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.
How do you recommend fitting an autoformatter into a programming workflow? I'm using pycharm
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?
Played around with it in the sandbox and immediately disliked its insistence on putting every item in a sufficiently-long array on its own line. For example, something like: foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 ] Black formats it to something more like: foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22…
If you add a single item to your preferred style, the entire thing has to be reflowed.
Having worked in Python for many years, I can tell you that nobody actually writes code that looks like Blacks formatting. It's a major step backward for the Python community.
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.
How do you recommend fitting an autoformatter into a programming workflow? I'm using pycharm
Earlier quoted context omitted.
yeah, someone above mentioned that with Go as the example. It's pretty nifty in some cases but think there are two sides to the story. I know folks who write lovely python code everytime. I know others at my gig who even after 3 years are not putting spaces after equals sign (and other PEP/flake8 blunders) and every PR is littered with syntactic errors. The code formatter is brilliant for this case.
I don't think making code written by hacks look like code written by a competent programmer is a good thing.
Earlier quoted context omitted.
How do you recommend fitting an autoformatter into a programming workflow? I'm using pycharm
Format on save. Failing that, format as part of your normal tox run. Failing that, pre-commit hook.
Earlier quoted context omitted.
CI runs a linter and fails the build if the output is non-empty. PRs can't be merged unless the build passes on the branch.
Yeah no because this changes the code and does not merely complain
Earlier quoted context omitted.
Yeah no because this changes the code and does not merely complain
One, that shouldn't matter on CI anyway. Two, you can tell black to just print the difference with --diff and tell it to just check the files with --check.
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…
That one actually makes a lot of sense to me, even if I've got to admit that I tend to go with the first option in my own code. It looks to me like a result of a couple rules that, in general, are sound: First, if an argument list can't fit all on one line, then every argument needs to go on a new line. And all the arguments need to be indented to the same level. The argument to that function includes the braces, so…
Maybe that would fail to put long strings on their own line?