Hacker News Reader

Comment by maratc | Hacker News Reader

Agree.

There's a python linter named `black` and it converts my code:

    important_numbers = {
        "x": 3,
        "y": 42, # Answer to the Ultimate Question!
        "z": 2
    }

into this:

    important_numbers = {"x": 3, "y": 42, "z": 2}  # Answer to the Ultimate Question!

This `black` is non-configurable (because it's "opinionated") and yet, out of some strange cargo cult, people swear by it and try to impose it on everybody.

View on HN

This is the flip side of "I’ve never understood why people care so much about the linter"!

Why are you caring about formatting? Just write your code, get it working, let Black tidy it up in the standard way. Don't worry about the formatting.

In cases where you're annoyed about some choice the formatter makes, somebody else would be equally annoyed by the choice you would rather make. There is no perfect solution. The whole point is to have a reasonable, plausible default, and to automate it so that nobody has to spend any time thinking about it whatsoever.

Running a standard formatter when code is checked in minimizes the source control churn due to re-formatting. That churn is a pointless waste of time. If you don't run a standard formatter, I guarantee that badly-formatted code will make it into source control, and that's annoying.

I may be unusual in a way I treat my profession and care about my professional output (the code I write), and I take both very seriously.

There's a quote from Steve Jobs (or maybe his carpenter father):

    “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”

When you say "Don't worry about the formatting", what you're saying is "use a piece of plywood on the back," and I'm just not going to do that.

I don't think we'll ever fully agree, but I'd just like to clarify that I value that kind of craftsmanship too!

I just honestly believe that if you fully automate the formatting, the results are better than if you do it painstakingly by hand; better by virtue of being more consistent. It's using the right tool for the job.

Did you read the example pietnas gave? The changed formatting ruined the communicative intent of his code. Formatters do that a lot, and it makes the code unambiguously worse.

I don’t really care about whether the back is plywood or whatever. I don’t know how to write plywood code. I do care about creating clear, readable code that communicates my intent. Sometimes formatters help with that. Often they hinder, as they reflect the arbitrary aesthetic preferences of their creators.

I don't see "pietnas" anywhere; do you mean the "important_numbers" example from maratc?

If so, I think a trailing comma is the correct fix, as described here: https://news.ycombinator.com/item?id=45168308

In this case I think the trailing comma is an improvement, so the formatter is steering you towards a better overall solution. However, even if you dislike the trailing comma, it's more important for the formatting to be consistent and robust, so I still think it's better to work within the limitations of the formatter.

I honestly have no idea where I read pietnas. The comment you identified was the one I was referring to.

I care about consistency, but not foolishly so. I suppose an important question is: under what circumstances is consistency undesirable?

I believe that consistency is not an end goal, but a means to achieve clear communication. When being consistent results in less clarity, it should be abandoned in favor of more effective communication.

That’s an obviously terrible formatting change. A format that prevents scoping comments narrowly is absurd. Why not just tuck all the inline comments at the end of the file so the code is denser while we’re at it?

It works the way you want if you add a trailing comma:

  important_numbers = {
    "x": 3,
    "y": 42,  # Answer to the Ultimate Question!
    "z": 2,
  }

You might complain that that seems a bit obscure, but it only took me 10 or 20 seconds to discover it after pasting the original code snippet into an editor.

The trailing comma is an improvement as it makes the diff clearer on future edits.

Edit to add: occurs to me that I oversimplified my position earlier and it probably looks like I'm trying to have it both ways. I do advocate aiming for clean and clear formatting; I'm just against doing this manually. You should instead use automation, and steer it lightly only when you have to.

For example, I explicitly don't want people to manually "tab-align" columns in their code. It looks nice, sure, but it'll inevitably get messed up in future edits. Better to do something simpler and more robust.

The trailing comma communicates an intent of possibly adding more things in the future. I actually use it quite a lot -- when I have that intent.

In the above example, if I think I have listed all of the `important_numbers`, there is a certain point of not having the trailing comma there.

Here's another terrible example from `black`:

From this:

    my_print(f"This string has two parameters, `a` which is equal to {a} and `b` which is equal to {b}", 
        a=1, b=2)

To this:

    my_print(
        f"This string has two parameters, `a` which is equal to {a} and `b` which is equal to {b}",
        a=1,
        b=2,
    )

The trailing comma it added makes no sense whatsoever because I can not have an intent of adding more things -- I've already exhausted the parameters in the string!

On the top of it, I don't quite get why I need to change the way I write in order to please the machine. Who should be serving whom?

Edit: changed "print" to "my_print" to not have to argue about named parameters of print ("sep", "file" etc.).

Edit 2: here's a variant that `black` has no issues with whatsoever. It does not suggest a trailing comma or any other change:

    my_print(f"This string has two params, `a` which is {a} and `b` which is {b}", a=1, b=2)

So an existence of a trailing comma is a product of string length?

Yes, it gets a trailing comma if it's on it's own line. That way when you add/remove arguments in a multi-line call it's only a one-line diff. This doesn't apply when the diff is only one line anyway.

Who's to say you don't add a new argument to the function in the future, like

    my_print(
        "This string has two parameters, `a` which is equal to {a} and `b` which is equal to {b}",
        a=1,
        b=2,
        color_negative_red=True,
    )

> it gets a trailing comma if it's on it's own line.

Sorry but it doesn't make any sense to me. If your argument is "a trailing comma is a good thing," it should go into any and all function calls/list declarations/etc. Who's to say I won't add this in the future:

    my_print("a={a}, b={b}", a=1, b=2, color_negative_red=True)

So do I need to have this now?

    my_print("a={a}, b={b}", a=1, b=2,)

There's a very responsive playground at https://black.vercel.app/ and whatever it does looks strange to me, because the underlying assumptions look inconsistent one with the other (to my eye at least.) Specifically, "the length of the string should decide whether there is a trailing comma or there isn't" makes zero sense.

>Sorry but it doesn't make any sense to me. If your argument is "a trailing comma is a good thing," it should go into any and all function calls/list declarations/et

No, the argument is quite specifically that a one line diff to add a new argument/element to the end of a list is preferable to a two line diff to do the same thing. The presence of the trailing comma is necessary to achieve that only when elements are on their own line.

Ok, we're then back to `print` example:

    print(
        'Hello there from a very long line abcdefghijklmnopqrstuvwxyz',
        sep=' ', 
        end='\n', 
        file=None, 
        flush=False,
    )

All of the existing named parameters to `print()` function are already provided, and that standard function is highly unlikely to change. Should I add another string to `print`, I will have to do it before the named parameters anyway. There is no sense in the trailing comma here however you look at it.

Edit: sorry for using single quotes, in my 20 years of writing Python it was never an issue, but now with `black` it apparently is.

I think this boils it down to the essence. Whether you use a trailing comma here, and whether you use single or double quotes, is just bike-shedding. If there's an automated tool that can make a consistent choice everywhere, that's worthwhile.

Putting a trailing comma stops that.

https://news.ycombinator.com/item?id=45169331

Reply on news.ycombinator.com