Hacker News Reader

Comment by Dangeranger | Hacker News Reader

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.

View on HN

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

Have you used the Visual Studio tools?

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

It's almost crazy to think this already isn't just a thing. Why is this just coming to a head now, after all these years of carrying on over code formatting?

I bet you heard of "go fmt".

Right, but that's a single relatively new language.

Many communities have been using their own solutions for it for a while (e.g pylint / pep8 if you've used Python, clang-format for C++, js-beautify for javascript, etc) and many companies use "linter as style enforcer" but you still need to watch out for some things that linters don't catch in most languages.

FWIW if you use vim, this plugin is great: https://github.com/google/vim-codefmt

I'm not convinced it is just coming to a head now. I've seen automatic/forced formatting on projects at least as far back as 2000, when I entered the workforce.

Yes, forced/automated based on that company standards. I'm referring more to universal.

The ones I've used for java have been consistently bad though. Autoformat as a commit hook leads to ugly code. Granted, I mean "bad" as in "gets ya 75% of the way".

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.

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 formatting preferences someone will pointedly defend.

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.

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

And this is why we have yet to converge. We are people, we have opinions! And some of us lead teams and make decisions.

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 mentions in passing that trailing commas require a diff that adds a field to modify two lines but one, but that applies to leading commas too if you add the field at the beginning of the list.

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.

Putting he comma at the start of the line allows for deleting any line without having to edit another (unless it's the first in which case the missing brace is more obvious IMHO.

The trailing comma is more easily missed I'd say.

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

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

Reply on news.ycombinator.com