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

141–150 of 159 posts

Re: A Prettier JavaScript Formatter

#141

Post by Noseshine »

balajics wrote: post #110

How is it different from jsbeautifier[1] other than enforcing its own style rules? [1] https://github.com/beautify-web/js-beautify

Looking at both github repos, jsbeautifier looks more complicated (as a project), and I don't think it uses the AST or at least I did not see anything that looked like it would create one. Looking at some of the code I saw `string.replace(...)` so it seems to be string-manipulation. It also is for HTML and CSS too it seems, while the project discussed here is just JS, so more targeted, and the approach to go through the AST seems intriguing to me.

PS: This seems to be the code for the JS beautifier in jsbeautifier: https://github.com/beautify-web/js-beautify/blob/master/js/l...

Re: A Prettier JavaScript Formatter

#142

Post by mhd »

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 wonder why this is suddenly accepted. Having very rigid coding standards used to be a no-go for projects you were either not paid for or in an industry where "creative expression" mattered more (i.e. not J2EE).

There were coding styles, but actually enforcing them wasn't something regularly done (linting is okay), for fear of "bondage & discipline" complaints.

Now the former "rock star" Ruby developers are embracing static typing and Ein Code, Ein Style formatting. Weird.

Re: A Prettier JavaScript Formatter

#144

Post by kimgronqvist »

hackcrafter wrote: post #15

I appreciate the emacs bindings [0]! Between this and eslint+flycheck I will feel less envious of Visual Studio Code's editor environment (if only there were a way to leverage some of its fantastic IntelliSense from emacs...) [0] https://github.com/jlongster/prettier/tree/master/editors/em...

Tide also works with normal javascript projects. All you need is a jsconfig.json at the root of your project. This gets you the same intellisense as VSC.

Re: A Prettier JavaScript Formatter

#145

Post by tony-k »

i guess i'm relatively new to javascript (can count years on one hand), but like many devs, i'm OCD about formatting and i'm a huge fan of eslint. i have found that curating a list of rules can require cycles (not to mention differences in opinion). i recently came across this project which had some allure, and i made note to try when i had a moment: https://github.com/sindresorhus/xo, how does "prettier" compare to this?

Re: A Prettier JavaScript Formatter

#146

Post by ocharles »

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.

This becomes very difficult when languages change their AST. Most languages are still evolving and the AST changes.

Re: A Prettier JavaScript Formatter

#147

Post by ocharles »

atombender wrote: post #129

gofmt — the official formatter of the Go language — made a very wise choice for its formatting strategy. I think it's something other tools can learn from. gofmt will fix indentation, spacing, and so on, but it will generally preserve structure. For example, this: a:=Foo{value:42} becomes, of course: a := Foo{value: 42} But! This: a:=Foo{ value:42, } becomes: a := Foo{ value: 42, } That's because gofmt can't really p…

> I often format code in a specific way for regularity:

I am trying to write my own formatter at the moment, and this is exactly the property I want, also. I'm working in Haskell, and one example is case statements. There are two ways I'd like to format them:

case foo of A -> ... B -> ...

or

case foo of A -> ...

  B ->
    ...
The first is when every case fits on one line, but the second is when at least one case needs to span multiple lines. I don't want this:

case foo of A -> ...

  B -> ...
I haven't yet come up with a good way to do that heuristically and efficiently, but maybe just looking at how the original code is formatted would be enough! Thanks for providing some food for thought :)

Re: A Prettier JavaScript Formatter

#148

Post by Vinnl »

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…

- It allows you to easily delete a line without needing to also modify the line before. - It also makes your diffs cleaner. With the latter, if you add a line, you'll also have to inspect the `radius: Float` line when doing a code review, even though it only added a comma.

Re: A Prettier JavaScript Formatter

#149

Post by jayrox »

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.

That's exactly how I feel about it. Line length is something I couldn't care less about. If it makes sense to be on one line, then it should be. Otherwise, create the new line where it does make sense.

Re: A Prettier JavaScript Formatter

#150

Post by benologist »

jeremy_wiebe wrote: post #124
benologist wrote: post #84

Earlier quoted context omitted.

Gofmt was the catalyst for me. I do it with StandardJS in Visual Studio Code on save automatically, I won't waste my time manually formatting code - or caring about it - again. Personal code formatting preferences is a problem. Devs should just let go of it, once it applies automatically your preferences quickly change. You can even wire up GitHub etc repos to automatically reject pull requests that add pointless for…

Can you point me to more information regarding Github and rejecting pull requests that are strictly formatting changes? Sounds interesting...

The formatters have command line programs that return error codes if a file requires fixing so you can require not getting an error from that in your testing or building process.
Post reply on HN