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

131–140 of 159 posts

Re: A Prettier JavaScript Formatter

#131

Post by DontGiveTwoFlux »

StevePerkins wrote: post #79
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 "catc…

Have you used the Visual Studio tools?

Could you point me in a direction to set this up on my system?

Re: A Prettier JavaScript Formatter

#132

Post by pitaj »

kansface wrote: post #106
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?

So people can easily read each other's code.

Re: A Prettier JavaScript Formatter

#133

Post by ud0 »

I'm already using and it works really nice, also submitted a pull request too. But one thing I've always looked for in formatters is still missing here, it's the ability to format the JSX in React.

It would be nice if the JSX in React's render could be formatted nicely because a lot of times the code get's so long that formatting and indenting becomes inaccurate.

Re: A Prettier JavaScript Formatter

#134

Post by sobani »

flukus wrote: post #123
eddyb wrote: post #121

Earlier quoted context omitted.

Think what happens when you break a line comment (or a string, in languages where it can't span several lines). And that's an easy example at that.

What happens? Nothing as far as I'm aware. The code is still one line.

> Because making the line wrapping nice requires deep syntax-aware editor integration.

'nice' is the key word here

Re: A Prettier JavaScript Formatter

#135

Post by elaijuh »

esbenp wrote: post #74

I made a VS Code plugin for Prettier https://github.com/esbenp/prettier-vscode It is my first VS code extension so have no idea if it is correct way. Feedback is welcome.

How to provide my options? Looks like it doesn't work on my vscode, it doesn't reformat max line length

Re: A Prettier JavaScript Formatter

#136

Post by devwastaken »

I was actually just looking for something like this the other day because I'm forced to use actual JS like a json config, so it can use Require to import XML data and sprite sheet location right into a config my application loads. Problem with all the other formatters is they made everything on new lines, which would take up a giant amount of space.

Would be cool to have this as a little website to try out, too.

Re: A Prettier JavaScript Formatter

#137

Post by stymaar »

pcwalton wrote: post #113
Strom wrote: post #108

Earlier quoted context omitted.

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.

> 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.

You don't usually code for one screen since you're not generally coding for yourself alone. IMHO unlimited line length + editor soft-wrap is the best way to deal with the problem since it automatically adjust the size to the reader's screen.

Same for tabs for indentation[1], that allows the reader to set its own indentation width depending on its own preferences.

I don't really understand why people keep using spaces + fixed line length. Old habits die hard I think.

[1] tabs for indentation, space for aligning

Re: A Prettier JavaScript Formatter

#139

Post by bjz_ »

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…

Yeah, I can second that recommendation on reading the paper [0]. It's one of the nicest I've read. There is also a Rust crate for it[1] - though it's not as... 'pretty'... as the Haskell EDSL, obviously.

[0]: http://homepages.inf.ed.ac.uk/wadler/papers/prettier/prettie...

[1]: https://crates.io/crates/pretty

Re: A Prettier JavaScript Formatter

#140

Post by jbergens »

toefraz wrote: post #128
russellbeattie wrote: post #69

My team recently ganged up on me to tell me my line spacing was f*cked. Upon reflection, it seems that as I'm writing code I group lines into 'working well - one line, 'not sure - two lines', 'probably will change - lots of space', 'hey look at me! - off by itself'. Apparently, this unconcious invisible system drives others crazy. Developers are so picky! ;-) We've actually got a bunch of automatic eslint rules, but…

There's a eslint rule for multiple blank lines

That one actually crashes in my atom installation. I get a warning that it cannot show me where the multiple empty lines are.
Post reply on HN