Hacker News Reader

Comment by alecbz | Hacker News Reader

OOC what are your grips with black's style? I generally find black pretty "beautiful" (concise maybe not as much).

Sometimes it takes code like this:

foo = (

    spark

    .read

    .parquet(...)

    .filter(...)

    .withColumn(...)

)

and turns it into

foo = spark.read.parquet(

...

).filter(

...

).withColumn(

...

)

which feels harder to parse for me. I also never quite got on board with the trailing commas.

Personally I prefer my code to read more like a sentence

instead

being

split

into

too

many

lines.

I guess the point of the parent applies when the parameter lists are long, thus breaking the sentence-like appearance of the chained calls.

These examples remind me why Elixir's pipe operator is so beloved.

Actually, modern versions of black will retain the fluent style you prefer, though it will collapse up to the first method call on the first line within the parens, so you end up with something like:

    foo = (
        spark.read.parquet(...)
        .filter(...)
        .withColumn(...)
    )

I guess the closing parens irk me the most e.g.

    assert outputs.get("foo.bar.baz", "default") == pytest.approx(
        time_recorder.time_taken, abs=0.0001
    )

I get why it's done that, but I just don't think it helps humans read. Part of the twisted beauty of PEP-008's narrow lines is that you're forced to extract (named) variables, or avoid overly indented code by extracting methods or applying higher level abstractions.

In the last few years I find devs are happier to format and push to "sort that problem out", leaving the readability benefit of that thought process lost.

TL;DR writing readable code isn't just about getting the spaces and brackets right...

I tend to prefer the trailing paren on the following line. I'm not sure if there's a principled reason it helps (or hurts), but stuff like:

    assert outputs.get("foo.bar.baz", "default") == pytest.approx(
        time_recorder.time_taken, abs=0.0001)

always feels a bit off and "unbalanced" to me. The opening paren doesn't have anything immediately following it, so it feels 'symmetric' that the closing paren shouldn't have anything preceding it.

And also it feels like the open and closing parens should be on lines that start at the same indentation level. Honestly this I think does aid in readability a bit.

> Part of the twisted beauty of PEP-008's narrow lines is that you're forced to extract (named) variables, or avoid overly indented code by extracting methods or applying higher level abstractions.

This feels orthogonal? The line is wrapping either way, which might sufficiently annoy someone to extract things out a bit more. But IMO it feels like a bit of an anti-pattern to create abstractions on the basis of syntax as opposed to the structure of the program.

> writing readable code isn't just about getting the spaces and brackets right...

? I mean of course not, but that's what we're talking about in the context of formatters right? I think the real, major way auto-formatters help with readability is by getting people to stop wasting mental cycles on things like spaces and brackets so that they can focus on more important code organization concerns.

I also prefer the close paren to be on it's own line. Besides how it looks, it feels easier to me to add to the code inside the parens (but this is likely because I use vim).

I agree with it feeling unbalanced. I don't register that statement as being complete. Putting the parenthesis on its own line is the same as putting a closing curly brace on its own line in languages that use those.

    int foo() {
        return 1; }

(This example actually breaks up vertically in my mind. As if it's just the number 1 being bracketed)

Maybe it could be broken up differently though to avoid the lone paren.

    assert (outputs.get("foo.bar.baz", "default") == 
        pytest.approx(time_recorder.time_taken, abs=0.0001))

This looks like bad coding style to me--trying to cram too much on a line and an overly complex conditional expression.

Using the same three lines, you could instead assign each result to a temporary var:

    x = outputs.get("foo.bar.baz", "default")
    y = pytest.approx(time_recorder.time_taken, abs=0.0001)
    assert x == y

If using an assert method, I think this looks okay too (although still a bit noisy):

    self.assertEqual(
        outputs.get("foo.bar.baz", "default"),
        pytest.approx(time_recorder.time_taken, abs=0.0001),
    )

I find that if black produces ugly output, it's usually because of something that I could improve, and I appreciate the hint.

Reply on news.ycombinator.com