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

71–80 of 159 posts

Re: A Prettier JavaScript Formatter

#71

Post by munificent »

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…

I will note that one could design a pretty printer that reliably had better performance if the formatting style they chose was simpler and more amenable to it.

My (mostly self-imposed) task was more difficult because I was trying to follow the existing style that humans were hand-applying to their Dart code, and that had a lot of tricky non-local cases that look nice but are hard to automate.

Re: A Prettier JavaScript Formatter

#72

Post by matthuggins »

tomp wrote: post #14

Nice attempt, but currently wrong. For example, it pretty-formats this code: function makeComponent() { return /*test*/ { a: 1 }; } into function makeComponent() { return /*test*/ { a: 1 }; } From my own experience writing a formatter, comments are very difficult (if one wants to preserve them). I guess the author should reparse the generated code to ensure the AST hasn't changed.

It also is not preserving JSX spacing correctly, and the example the site provides even shows that:

    JSX issupported
Note the lack of space after the word "is".

Re: A Prettier JavaScript Formatter

#73

Post by chriswarbo »

jlongster wrote: post #47
rhengles wrote: post #28

How does this handle tabs vs spaces? I looked the post, the repo and the issues page and I didn't find anything. I'm specially concerned about not seeing this in the options of the API, since there are strong opinions on both sides.

It always prints spaces and you can configure the number of spaces with `--tab-width`. For tabs/spaces and semicolons I'm considering if we should support those options. We need to figure out the goal of the project: is it to converge on generally a single format, or is it to provide formatting options for a few large groups of people that have different opinions. There are issues on the project discussing this right…

Whilst it's easy to flame about tabs vs spaces and other bike-sheddy issues online, I wonder how much people really care about it? After all, many people just get on with life when it comes to non-optional syntax, e.g. whilst many people flame about Python's use of significant whitespace, I doubt that's been a major reason for many people to actually use a different language, or some semicolon-and-braces-to-indentation preprocessor.

Perhaps stick to just one, as seems to be the case right now (whichever it is), and mention in the documentation that those wanting the other option are free to e.g. write a patch/fork on GitHub/postprocessor/etc., with the understanding that such support will eventually get merged in iff it's actively maintained for some amount of time, its author/maintainer is active in general development and maintenance for the project, and there's significant community adoption of such a patch.

Whilst not perfect, this sort of approach might better determine who actually cares enough about this to offset the community-splitting effects of allowing both; compared to a general accumulation of online grumbling.

Re: A Prettier JavaScript Formatter

#77

Post by gravypod »

"There's an extremely important piece missing from existing styling tools: the maximum line length. Sure, you can tell eslint to warn you when you have a line that's too long, but that's an after-thought (eslint never knows how to fix it). The maximum line length is a critical piece the formatter needs for laying out and wrapping code."

I'd disagree. See https://www.youtube.com/watch?v=wf-BqAjZb8M

Re: A Prettier JavaScript Formatter

#78

Post by tomp »

n42 wrote: post #54
dangoor wrote: post #30

Earlier quoted context omitted.

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.

The entire comment was patronizing. "Nice attempt" minimizes the effort involved and implies the author is a novice. "but currently wrong" categorizes the entire project as a failure because of a single bug. The followup "From my own experience writing a formatter" really drives the whole thing home.

Wasn't meant that way.

Re: A Prettier JavaScript Formatter

#79

Post by StevePerkins »

Dangeranger wrote: post #58

After using Elm and the elm-format package in Emacs for the last few weeks I can say that not having to format the source and just letting your editor do it for you on save or via a command is so very nice. This is a trend that I feel is going to catch on across any language that can support it. It makes trivial decisions and arguments about formatting a thing of the past.

> This is a trend that I feel is going to catch on

This has been pretty standard practice in the boring ol' enterprise for at least 10 or 15 years.

Java has Checkstyle, with format-on-save support for IntelliJ, Eclipse, and NetBeans at the very least. Visual Studio supports this for all of the .NET languages. Obviously, Golang has `go fmt`. Etc.

Not to be snarky, but whenever a bold new trend seems to be really "catching on"... it's almost always a rehash of something that the enterprise was doing back in the 90's, or academic researchers were writing papers about back in the 70's. The only things that ever really change in this industry are: (1) solutions that were once impractical on old hardware become practical on newer hardware, and (2) solutions that were over-engineered in their original form come back in more user-friendly simplified forms.

Re: A Prettier JavaScript Formatter

#80

Post by K0nserv »

pcwalton wrote: post #36
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, includi…

Yeah that's a good point. I was referring more the general idea of enforcing style by parsing the code and reconstructing the source from the AST though. This is a better method than the linter approach that you get with eslint for example.
Post reply on HN