Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Prettier JavaScript Formatter

jlongster.com

Post reply on HN
Print view View original

31–40 of 159 posts

Re: A Prettier JavaScript Formatter

#31

Post by evmar »

jlongster wrote: post #13
evmar wrote: post #4

How does this compare to clang-format, which also formats JavaScript and also (to use one of the features highlighted in the article) obeys line length?

Not sure, didn't know it formatted JavaScript! This is written in JS at least so if anything it's more approachable to the community.

Yes, that's a good point. If you ever get a chance to compare to clang-format I'd be interested to read your results. My vague understanding is that clang-format has some sophisticated-ish algorithms for intelligently wrapping complex expressions. However, I also think its output is inferior on code like your .then() chain example.

Re: A Prettier JavaScript Formatter

#32

Post by harpocrates »

sharpercoder wrote: post #5

> If computers are good at anything, they are good at parsing code and analyzing it. So I set out to make this work, and prettier was born. I didn't want to start from scratch, so it's a fork of recast's printer with the internals rewritten to use Wadler's algorithm from "A prettier printer". Bob Nystrom (munificent) disagrees[0] after writing one himself: > The search space we have to cover is exponentially large, a…

This is a great read! From having dipped my toes into this, I'd say a large part of the problem (from the library designer's point of view) is deciding what interface to expose to the library user and making that as language agnostic as possible. The question becomes: what are the fundamental things that usually characterize pretty-printing? Obviously (or maybe not), you'll want indentation, hard-breaks, soft-breaks, ... but where does it end? Less obviously, you may want to have alignment features. Figuring out the right set of building blocks is what I think Wadler did well.

Also, describing how these building blocks interact using laws is really incredibly useful! For that, credit goes (I think) to Hughes [1].

[1] http://www.cse.chalmers.se/~rjmh/Papers/pretty.ps

Re: A Prettier JavaScript Formatter

#33

Post by chc »

SomeCallMeTim wrote: post #29

Flow is cool, but TypeScript has way more traction. Would jump on this in an instant if it had TypeScript support and a VS Code plugin.

Typescript is another language. It kind of goes without saying that people using a different language be more likely to use something if it were in the language they use, doesn't it?

Re: A Prettier JavaScript Formatter

#34

Post by evmar »

SomeCallMeTim wrote: post #29

Flow is cool, but TypeScript has way more traction. Would jump on this in an instant if it had TypeScript support and a VS Code plugin.

clang-format supports TypeScript and has a VS Code plugin. (See my other comment in this thread for some discussion of the differences between the tools.)

Re: A Prettier JavaScript Formatter

#35

Post by acdha »

Touche wrote: post #21
rhengles wrote: post #7

Much better than "Standard JS" and its choice of no semicolons. I know about "Semi Standard JS", but I refuse to accept such a little difference that could be a configuration has to live in a entirely new project.

Note that Standard is a linter, this is a reformatter. Standard gives you errors but doesn't fix things for you.

https://github.com/feross/standard#is-there-an-automatic-for...

“You can use standard --fix to automatically fix most issues automatically.

standard --fix is built into standard (since v8.0.0) for maximum convenience. Lots of problems are fixable, but some errors, like forgetting to handle the error in node-style callbacks, must be fixed manually.”

Re: A Prettier JavaScript Formatter

#36

Post by pcwalton »

K0nserv wrote: post #9

This looks really nice. One of my favourite things about Golang is the use of gofmt and the resulting consistency of all Go programs. The idea of parsing the code to AST representation and then printing it back as source is brilliant, all though it can mess stuff up like the chaining of `.then` as mentioned in the post.

gofmt doesn't solve the hard problem that this blog post (and Wadler's paper) is about. From the article: "There's an extremely important piece missing from existing styling tools: the maximum line length."

gofmt's decision to not bother to require a line length may work somewhat for Go (which tends to encourage short lines by virtue of lacking expressiveness), but it doesn't work for lots of other languages, including JavaScript.

Re: A Prettier JavaScript Formatter

#37

Post by Touche »

chc wrote: post #33
SomeCallMeTim wrote: post #29

Flow is cool, but TypeScript has way more traction. Would jump on this in an instant if it had TypeScript support and a VS Code plugin.

Typescript is another language. It kind of goes without saying that people using a different language be more likely to use something if it were in the language they use, doesn't it?

I mean, by any reasonable definitely of a language, Flow is another language too.

Re: A Prettier JavaScript Formatter

#38

Post by acdha »

dangoor wrote: post #30
mi_lk wrote: post #26

Earlier quoted context omitted.

the parent gave an ill example and suggest a solution, how's that a negativity?

I believe it was the "Nice attempt, but currently wrong." at the start of the comment. "Nice attempt" could imply that this should be thrown out in favor of another attempt to solve the problem.

Also, “currently wrong” is a really sweeping statement to make based on a single problem written in a fairly uncommon style. Yes, there are things which need to be fixed but that doesn't mean we have to be so dismissive of someone else's work which they've given away for free to the community.

Re: A Prettier JavaScript Formatter

#39

Post by richie5um »

K0nserv wrote: post #9

This looks really nice. One of my favourite things about Golang is the use of gofmt and the resulting consistency of all Go programs. The idea of parsing the code to AST representation and then printing it back as source is brilliant, all though it can mess stuff up like the chaining of `.then` as mentioned in the post.

I completely agree. What is, for most programming languages / code, a huge waste of time and huge amount of annoyance becomes something you no longer have to deal with.

Having choices can be nice, but it introduces a huge amount of cognitive load. And, really, if we all just use the same format, we'll all (eventually) get used to it.

We really do have better things to deal with than formatting style.

Re: A Prettier JavaScript Formatter

#40

Post by kasbah »

rhengles wrote: post #7

Much better than "Standard JS" and its choice of no semicolons. I know about "Semi Standard JS", but I refuse to accept such a little difference that could be a configuration has to live in a entirely new project.

But the linked formatter doesn't seem to have an option for no semicolons so I wouldn't call it better in that regard.

EDIT: Looks like they may be open to it though. https://github.com/jlongster/prettier/issues/12

Post reply on HN