Comment by myfonj | Hacker News Reader

Comment by myfonj | Hacker News Reader

I think that For c-like syntaxes that have mostly `(, , )` and `; ; ;`patterns -- i.e. start (opening) and end (closing) delimiters with tokens inside separated by separators -- the most rational formatting is really to push *all delimiters to the left and let the closing delimiter dangle*.

Indeed, feels super unusual and tooling is lacking, but behold the concise rationality:

    ; const url
      = "..."
    ; const contact
      = { "firstName"
          : "John"
        , "lastName"
          : "Smith"
        , "address"
          : { "streetAddress"
              : "21 2nd Street"
            , "city"
              : "New York"
            , "state"
              : "NY"
            , "postalCode"
              : 10021
            }
        , "phoneNumbers"
          : [ "212 555-1234"
            , "646 555-4567"
            ]
        }
    ; const result
      = sendData
        ( url
        , contact
        )
    ; rejoice
      ( result
      )

Beauty. N.B. those opening and closing delimiters "connected" by breadcrumbs of separators. Isn't it lovely?

Most developers I know will immediately lit torches and grab pitchforks if you show them this.

(Personally, I'm using it sometimes for private doodling, and while reformatting obfuscated or exploring some complicated codes; mostly just to improve own reading comprehension.)

If you relax the rule to allow "single simple value" to be in the same line (so break the rule for "=" / ":" on the start of the line), it could look lie this [1]

[1] https://eldar.cz/myf/lab/_sandbox/indentation.html

If the syntax allows for a trailing separator, I'd go with opening delimiters and separators on the right, with a trailing separator, and the closing delimiter on its own line.

The reasoning behind that is that it produced the cleanest diffs with source control - especially if you consider changing the first/last/only entry in a collection.

Consider the diff from removing the first phone number from your collection above, and compare that to removing it from

    "phoneNumbers": [
        "212 555-1234",
        "646 555-4567",
     ],

> the most rational formatting

By which metric is that rational? IMO it is utterly unreadable.

> Most developers I know will immediately lit torches and grab pitchforks if you show them this.

Yes I will do just that now lol

Prettier was invented so we don't have to deal with this bullsh*t anymore. What a gift of god

Rational in sense that syntactically most significant characters are swept to one side: - left. So they can be observed (checked) in a single glance.

In contrast of the conventional ("irrational") zig-zag pattern where: - starting delimiter is somewhere in the middle of the line (if not in Allman and similar style); - separators are mostly at the right end of the line, sometimes pretty far, depending on line length; - closing delimiter is mostly on the left. - Plus separators and delimiters can be scattered among single line, if they "fit" there.

Again, I'm not telling this is "good and YoU ShoULD USe thAT!1!", only that compared to rules of other conventions I see least amount of "rules" and "exceptions" in this. And it is usable only in syntaxes with separators (JS to some degree, JSON, CSS), not for languages where ";" must finish even the last statement in a block (PHP) - there you'd have dangling two characters.

As for readability, I concur, yet I'd be very cautious of raising judgments like "it is utterly unreadable". I know that readability is largely matter of habit and I'd not be surprised that if we lived in such "Haskely" alternative universe where this convention was a norm from the start, we'd probably scream in terror when confronted with "Prettier" ("Stroustrupy") conventions.

I'm not sure about the metric of "syntactically significant", though. Semicolons are definitely important for the compiler, but they're usually very unimportant for the human writer and reader of the code - if they are present, they can be ignored, and if they are not present, then the IDE can indicate that fairly reliably, regardless of where in the code it sits. When editing, they are rarely particularly present in my mind. And given that for the compiler - the only entity that does need to be aware of them - it doesn't matter at all where they go, it doesn't seem useful to emphasise them in this way.

It makes sense, but I really think it is a matter of habit. You can similarly "ignore" those separators and delimiters where you have them now as you can "ignore" them on the left. (There you can for example mentally "blend" them with indentation.)

That "emphasis" you are talking about is probably just that they seem unusual so they draw attention.

Elm typically leans into this exact style (though without semicolons)! It's refreshing seeing support for this delimiter-first, dangling closing delimiter style in a more imperative and mainstream language.

If you make `; ` into `;\n`, it if perfectly readable. When trying to sort, where a scope, call or line actually ends, I like to do that, too. But more git friendly, i.e. either split `: [ "212 555-1234"` in two, or move colon up and often add a commented out `//,` for completeness at beginning or end if not allowed

>but behold the concise rationality

I'd change careers if I had to format or read code like that...

Reply on news.ycombinator.com