undefined | Better HN

0 pointsdeclnz4y ago0 comments

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

0 comments

alecbz4y ago

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.

ziml774y ago

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

philote4y ago

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).

saila4y ago

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.

j / k navigate · click thread line to collapse