Black, the uncompromising Python code formatter, is stable

Re:Black, the uncompromising Python code formatter, is stable by Alex3917 on Saturday January 29, 2022 @04:59PM (#30130968)

The problem I have with it is that, to me, these are super readable:

    x = [ 1, 2, 3 ]
    y = { 'a': 1, 'b': 2 }

Whereas these are not:

    x = [1, 2, 3]
    y = {'a': 1, 'b': 2}

To me, declaring inline lists and dicts without the leading and trailing space makes it more difficult to see what the data structure is, and what it contains. This is especially true when you have lists or dicts declared inline as arguments to functions, e.g.:

    my_function_call([ 1, 2, 3 ])

versus:

    my_function_call([1, 2, 3])

While it's generally not good style to declare data structures inside function calls, at least with the space it's still somewhat apparent what's happening, whereas without the space it just looks like three positional arguments. I love the idea of black, but in practice I'm not going to use something that changes my own code into something that's more difficult for me to read.

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by NavinF on Saturday January 29, 2022 @05:17PM (#30131142)

That’s gotta be a really unpopular opinion since I’ve never seen anyone write “[ 1, 2, 3 ]” instead of “[1, 2, 3]” in the last 10 years or so.

If anything I’m seeing the opposite trend with a few devs writing “[1,2,3]” so that large constant literals don’t overflow the line.

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by LegionMammal978 on Saturday January 29, 2022 @05:51PM (#30131416)

I've recently been working with an old C++ codebase that formats every function call like this:

  Foo<Bar,Baz> value = some.method (1, 2, 3 + 4) ;
  // or with no parameters:
  value = some.method() ;

I've never seen it anywhere else, and it took me a good week to get used to it.

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by goblin89 on Saturday January 29, 2022 @09:57PM (#30133433)

You might not have been writing JavaScript. For objects, spacing properties from curly brackets is pretty much the norm, Prettier does that by default. For lists I see it rarer but I personally use it instinctively for consistency with objects, especially with things like useState destructuring and ([ complex, ...splatting, ...combinations ]) into function calls (which admittedly becomes uncomfortably terse).

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by goblin89 on Sunday January 30, 2022 @06:56AM (#30136271)

And here’re some fresh examples with lists just encountered in the wild: https://developer.matomo.org/guides/tracking-javascript-guid...

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by mech422 on Saturday January 29, 2022 @10:02PM (#30133456)

FWIW, I do "[ 1,2,3 ]". So we exist, perhaps you just haven't bumped into us :-)

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by spiderice on Saturday January 29, 2022 @05:07PM (#30131051)

My only response to this would be “get used to it”.

I used to think 2 space tabs made code harder to read than 4. Now I used 2 spaces and I’ve gotten used to it and can read it fine. And I have no doubt you could learn to read the black formatted code just as easily. I can, since that is how I format my code anyway.

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by bfung on Saturday January 29, 2022 @07:16PM (#30132105)

Agreed - end of day, code formatting is not that important in the context of how end users utilize the product.

Read a lot of different code and programming languages. They all look pretty much the same after awhile, formatting and syntax.

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by solarmist on Saturday January 29, 2022 @09:12PM (#30133130)

I think it just doesn't matter anymore because almost all editors support code folding and visual markers for it, making it MUCH easier regardless of 2 vs. 4.

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by Alex3917 on Saturday January 29, 2022 @08:50PM (#30132956)

> I used to think 2 space tabs made code harder to read than 4. Now I used 2 spaces and I’ve gotten used to it and can read it fine.

I might be in the minority, but it's an empirically testable proposition. Given the thousands of people taking Python quizzes for toptal, triplebyte, etc., it should be possible to see which version results in a lower time to answer or a higher accuracy rate.

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by d12bb on Sunday January 30, 2022 @04:15AM (#30135255)

And that’s the reason everyone should use tabs. You like 2, I like 4, someone else one the team likes 3, 6, 8, whatever? No problem if tabs are used, everyone can set tabstop to their liking!

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by heavenlyblue on Saturday January 29, 2022 @06:38PM (#30131783)

Just learn how to make them readable. I am yet to see a single developer who didn’t manage to learn that. Seriously, the worst types are the ones who think they are experienced enough to think what “is more readable”. It’s all a matter of habit.

[ Parent | on HN ]

Re:Black, the uncompromising Python code formatter, is stable by gmfawcett on Sunday January 30, 2022 @10:42AM (#30138087)

I disagree: your style is less readable than Black's. You've moved the data-structure syntax away from the data, and toward the function-call syntax, causing them to blend together.

This would be more readable -- put the space around the structure, not inside it:

    my_function_call( [1, 2, 3] )

Now we can clearly see the separation of the argument from the function call. But I wouldn't bother switching code formatters just to have this.

[ Parent | on HN ]