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

151–159 of 159 posts

Re: A Prettier JavaScript Formatter

#151

Post by chriswarbo »

IvanVergiliev wrote: post #143

Eventually we should just store the AST in source control. Prevents inconsistencies when style changes and/or 50k lines diffs to change the indentation level.

I certainly think that language definitions should include a standard parsed format in addition to their human-friendly syntax. This can just be an s-expression representation of the normal, concrete syntax, without any transformations applied. This way, we don't have to build language-specific rules for precedence, offside/significant-whitespace, fixity, etc. into every tool for that language.

Implementations (compilers and interpreters) should include tools/modes for converting between these two representations, and should support running programs written in the parsed format in addition to those written in the human-friendly syntax. This isn't asking much: the difficult part is parsing the human-friendly syntax, which implementations must already do.

The benefit is that we don't end up with a mismatch between what the compilers/interpreters accept, and what the other tooling accepts (linters, formatters, doc generators, static analysers, search engines, syntax highlighters, use-finders, go-to-definition, refactoring tools, etc.). This would, incidentally, allow people to read and write code as s-expressions, but that's not the point; it's just about representing concrete syntax as closely as possible (plus arbitrary annotations, e.g. for line numbers, etc.), whilst exposing the structure in a machine-friendly way.

This would also make it much easier to make new tools, extend existing ones, and improve practices, e.g. like syntax-aware diffing, standard code formatting (i.e. tools like this one), version-control-friendly representations, tree-based editors, more powerful navigation in editors and IDEs, etc.

Re: A Prettier JavaScript Formatter

#152

Post by pcwalton »

flukus wrote: post #120
pcwalton wrote: post #113

Earlier quoted context omitted.

> The fact that gofmt doesn't enforce some arbitrary line length is a blessing. You don't have an infinitely long screen. You have some line length limit.

It's infinitely scrollable though. Scrolling horizontally sometimes isn't a bad fallback.

Scrolling horizontally interrupts flow like nothing else!

99% of all software projects have a de facto or de jure line length limit for a reason.

Re: A Prettier JavaScript Formatter

#154

Post by robbrown451 »

gcommer wrote: post #101
robbrown451 wrote: post #93

Would it be reasonable to have an editor that ran this every time you resize your editor window? I like to have multiple windows on screen at once, and will often adjust them to make best use of screen real estate. I tend let it soft-wrap the text, but I'd love it if it would do soft-wrapping... prettier.

That sounds like an awesome idea (given that display is totally separated from the format-on-save anyways). I got a quick feel for it with this in a terminal: watch -n 0.1 'prettier --print-width $COLUMNS index.js' ... and unfortunately didn't really like it. Maybe in a pinch, but it still ends up feeling really cramped trying to read column in low-width terminals. At the other extreme (having the terminal be the onl…

I'm playing with this in CodeMirror (browser based code editor) which talks to a local node.js server, and I think it looks really good, as long as you have lower and upper limits as you suggest. Biggest concern is stuff like the undo history. I think it just needs a "formatting" button or even background process when you leave it idle for a bit. Might be better to run on the browser but haven't bothered trying yet.

Re: A Prettier JavaScript Formatter

#155

Post by fanf2 »

Strom wrote: post #108
pcwalton wrote: post #36

Earlier quoted context omitted.

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…

The fact that gofmt doesn't enforce some arbitrary line length is a blessing. I have a modern widescreen monitor and I use a maximized window text editor. I have no problem with 200 char length lines. I'm more easily annoyed by 80 (or 60, like in this case) char limits, as if I was viewing this code on punch cards.

I like to divide my screen into multiple windows each 80 or 90 columns wide, so that I can see several source files at the same time, or code and documentation and shell windows.

Line length limits help me to make really effective use of big screens.

Re: A Prettier JavaScript Formatter

#156

Post by piyush_soni »

In the section of 'respecting patterns', I was really expecting that it'd maintain my style of curly braces if they're already there, which has same indentation level (and on new line) for a function's opening and closing braces.

e.g. :

function something()

{

}

Re: A Prettier JavaScript Formatter

#157

Post by tlrobinson »

Semiapies wrote: post #90
tlrobinson wrote: post #89

Earlier quoted context omitted.

I avoid opinionated lint rules because it's annoying to retrain yourself, but if my editor does all the work and it's readable enough I'd love to adopt this or something like it. The version control issues might be a blocker though. It would be neat if git had a way to do diffs at the syntax tree level.

Would using the git diff with whitespace ignored not help?

Prettier inserts missing semicolons, but otherwise maybe.

Re: A Prettier JavaScript Formatter

#158

Post by erikpukinskis »

harpocrates wrote: post #6

I really have to back up the recommendation for Wadler's "prettier printer" paper. I'm working on a Haskell parser and pretty-printer for Rust and I had pretty much given up on ever finding a lightweight pretty printer that would be able to choose whether to put something on one line or to split it up into multiple lines all by itself. For anyone needing this in Haskell, I strongly urge you to consider the modern rew…

I think there's beauty in the best you can do with a very simple implementation.

Even if you can improve "prettiness" with heroic technical efforts, I think the end result would be uglier. There's something special about simple rules coming together to address just the most important needs.

In the tech world, we tend to put more finesse into things... because we can. But as a result, most software is over-finessed and therefore not finessed at all. A great example is how tortured we let our CSS rules get, rather than allowing a design to relax a little into the constraints of the layout engine.

A hand-set newspaper isn't beautiful because it overcame every constraint, it's beautiful because it accepted its constraints, and made hard tradeoffs in service of a goal.

Re: A Prettier JavaScript Formatter

#159

Post by bastih »

amenghra wrote: post #81

https://github.com/facebook/pfff is a tool which support pretty printing a bunch of different languages (currently c, c++, java, js, php, python, rust, and a bunch more). The idea is to have a common AST (with parsers for each language) which keeps track of whitespace/comments/etc and then share a ton of logic by writing writing code at the AST layer. You can use pfff to pretty print according to your style needs. Al…

I've looked at pfff and couldn't really figure out what's supposed to work and what isn't. Would love to pretty print python with it. (I've been looking at the many different pretty printers in the python world and haven't found anything that I feel works well enough). Did you use it for pretty printing python?
Post reply on HN