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

101–110 of 159 posts

Re: A Prettier JavaScript Formatter

#101

Post by gcommer »

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 only window on a 21:9 ultrawide), some of the lines get so long that you'd want a max anyways.

Re: A Prettier JavaScript Formatter

#102

Post by gsylvie »

joshwcomeau wrote: post #91
BrandonM wrote: post #88

If I personally prefer the second Promise chain: myPromise.then(() => { // ... }).then(() => { // ... }).catch(() => { // .. }); and if I also prefer the Lisp-like approach and hate putting: ); on its own line, am I part of the problem? What if my whole team uses that style? For example, we would write: foo( reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne() ); as: foo(reallyL…

I think that this is definitely not a tool for everybody, and I think that's alright. Dan Abramov said it best, when he opened an issue urging to resist the urge to add configuration: https://github.com/jlongster/prettier/issues/40 Configuration has a cost, and the product will be better and more reliable if it's limited. As it stands right now, the configuration isn't ideal for my preferences, but I'm fine with that…

I find if I hate a formatting pattern that I'm forced to use, after a while I prefer it and hate all others.

Re: A Prettier JavaScript Formatter

#103

Post by munificent »

korm wrote: post #98
munificent wrote: post #71

Earlier quoted context omitted.

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.

I have to say Dartfmt is one of my favorite things about using Dart. It works amazingly well and the fact that it's not configurable is a great decision [0]. I'm never afraid to peek into unfamiliar code because of that. So thank you. [0] https://github.com/dart-lang/dart_style/wiki/FAQ#why-cant-i-...

You're welcome! That means a lot to me. I tried really really hard to make it produce output I and others would like.

> I'm never afraid to peek into unfamiliar code because of that.

This is exactly why dartfmt exists. It's not about making your code more readable to you, it's about making strangers' code more readable, because that lowers the bar to contribution between people in the ecosystem.

Re: A Prettier JavaScript Formatter

#104

Post by zem »

zem wrote: post #68
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.

i hate the output of elm-format, though :( it's very wasteful of vertical space.

this diff, right here, is what i'm complaining about. i decided to bite the bullet and start running elm-format since it was part of the 0.17->0.18 automigration tool, but it has yet to grow on me.

https://github.com/martindemello/crosspad.elm/commit/c67deb4...

Re: A Prettier JavaScript Formatter

#105

Post by icebraining »

richie5um wrote: post #39
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.

It also helps if you want to write code conversion tools, like gofix. I once stopped writing such a tool for a Python project because it was a pain trying to change only the affected lines, while keeping the idiosyncratic syntax of the rest of the files unaffected.

(By the way, for people trying to do the same, I recommend the redbaron library, which makes it much easier to handle: https://github.com/PyCQA/redbaron)

Re: A Prettier JavaScript Formatter

#106

Post by kansface »

geuis wrote: post #11

Fantastic. One thing I've learned that's incredibly important is code style has to be uniform across all engineers. Seems like an unimportant point to devs that haven't worked with teams that enforce it, but it really is. As was once told to me, my code should look like your code and yours like mine.

> One thing I've learned that's incredibly important is code style has to be uniform across all engineers.

Honestly, why does this matter at all?

Re: A Prettier JavaScript Formatter

#107

Post by jkochis »

david-given wrote: post #100
zem wrote: post #68

Earlier quoted context omitted.

i hate the output of elm-format, though :( it's very wasteful of vertical space.

Tangential question: Why do Haskell and Elm format lists like this? type alias Circle = { x : Float , y : Float , radius : Float } ...and not like this: type alias Circle = { x : Float, y : Float, radius : Float } ...? The first makes me shudder with revulsion every time I see it --- that's not where commas go , dammit --- and there must be a reason, which I've never been able to figure out. The Elm style guide menti…

I get why this bothers a lot of people, but OTOH I get why some people like it. I think the reason for the former in the mind of the user is that the comma clearly signifies that you are adding another value after it, and you save valuable key strokes not having to add a comma to the end of the preceding line just to add another k:v on the line you're concerned about.

Re: A Prettier JavaScript Formatter

#108

Post by Strom »

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…

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.

Re: A Prettier JavaScript Formatter

#109

Post by flukus »

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…

Why does the formatter need to solve this and not the editor? The editor has more information available to it, like the present screen space.
Post reply on HN