I think,
type Msg = AddCalorie | Clear
is clearer than,
type Msg
= AddCalorie
| Clear
and also more meaningful in a first glance for a new comer.
Even if we make it this long,
type Msg = AddCalorie | Clear | Something | Whatever | Nothing | Anything
still it’s not too long.
Why not split it after it reaches certain letters of length, otherwise keep it as one line?
You should also consider examples (even short ones) in which some of the constructors take arguments.
5 Likes
Yes, in that case more than 3 constructors won’t fit in a line.
Well, it’s all subjective, isn’t it? You might see something as more clear than something else, while I might disagree.
In practice, it doesn’t really matter how code is formatted, but that it is done so consistently.
There are two benefits to the way elm-format currently formats the code you’ve posted:
- It’s a very simple rule. Each constructor of the custom type gets a line of its own. That is much simpler than: each constructor is on a single line unless it has more than x parameters or if the line is y long (btw, what is too long? 80 chars? 100 chars? 120 chars?)
- It’s very
git difffriendly. It’s easy to see what exactelly has changed when everything is on a seperate line. Which helps when doing code review.
19 Likes
I guess the best option is to do it the same as function calls with parameters… if you do it on one line it stays on one line, if you bring one argument down, all of the arguments get their own line.
Then you do not need to think of lengt in rules…
But I really like the first example. I like one custom type for each line as it is.
2 Likes
Prettier in JS land will reformat based on length. Personally I dislike this, it makes for noisy diffs in PRs.
If anything I would like to see the first element equal as the others, so you can remove it and sort easier than now. (not valid Elm though) e.g.
type Msg
| AddCalorie
| Clear
5 Likes
Look at this example.
This one,
looks clearer and more meaningful than this one,
or even this one,
if Elmers / Elm Programmers / Elm Community / “Programmers” don’t feel it a shame to listen to a newbie like me. Because a newbie will decide which language s/he felt digestible at a first glance, and once s/he finds a language digestible, s/he will start learning it, and that’s the way other technologies (languages/frameworks) grow their communities.
(I came to learn Elm because of it’s benefits which I’ve listed in another post at elixirforum. Had I seen an example like the second image in this reply, I won’t ever had the guts to try to learn a language in which creating a div with 3 elements looks that scary).
I agree that the current format for lists is not optimal, but that is different from the custom type above. For HTML I would like to see this:
To me it resembles Html a lot more and I find it easier to read (not valid Elm again unfortunatelly).
3 Likes
I started learning Elm a few months ago, and also found elm-format’s output quite difficult to stomach at first. A week or two in though, I got used to it, and it feels quite normal now. I’ve actually grown to appreciate the extra spacing!
So for those still very new to Elm, my advice would be to wait a few weeks and see whether your thoughts on this evolve 
(Your opinion might stay the same, and that’s okay - just give it some time to make sure )
11 Likes
I think it’s great that you’re engaging with the community and challenging how things currently work. But just as you feel that it would be a shame if the elm community isn’t listening to you, I also think it would be a shame if you didn’t listen to folks of the elm community.
-
elm-format is a completely optional tool. It’s not an official part of the elm distribution. The elm/core library isn’t formatted with it. You can format code however you like. How code is formatted doesn’t really matter, as long as it’s consistent. The reason people choose to use elm-format is because a lot of us are tired of having discussions internally in our projects about how code should look (everyone disagrees), and so using a tool fixes this problem for us.
-
A lot of people didn’t like elm-format at first (including me), but you get accustomed to it pretty quickly. In fact, I can’t imagine writing Elm without it. If you don’t feel the same way, then you don’t have to use it.
I also took the liberty to read the post you linked to over at elixirforum and would like to add two points:
-
Elm 0.19 is very recent, and it’s a breaking change. Most packages are already ported over, and the rest will come in time.
-
Elm 0.19 actually does have builtin dead code elimination. You need to compile with
--optimize. You can read more about how small Elm assets really get here: news/small-assets-without-the-headache
12 Likes
@Sebastian I like the idea of having every line in a list of items be identical (ie even the first item allows a comma), that’s similar to how its done in rust. Make it less fiddly to reorder the items with line cut and paste operations. In rust though, the extra comma is after the last item.
My main beef with the elm-format output is four spaces for indenting rather than two. I have more vertical space than horizontal space to deal with, it’d be nice to have more indenting visible.
2 Likes
Yes, looks like I’m also getting used to it, like I said at elixirforum,
When I was a js developer I spent approximately a hundred hours arguing with my team about formatting style. At the end of my frontend career I came to some sort of enlightenment: it doesn’t matter how code is formatted as long as every maintainer of a codebase follows local convention. Still though we were angry at each other about made linter choices. I am so happy that I don’t have such time and money and emotions draining topic in elm and golang.
11 Likes
Why does Elm use so many newlines? Mainly because of git diffs, I think. A lot about how elm-format formats elm code is well-suited for small and easy-to-understand git diffs. If we have a threshold where all layout changes, diffs get really messy.
Then, there’s a huge argument to make about consistency. If the formatting is consistent enough, I can tell within seconds how much of a module is idiomatic code. I can also tell if something sticks out, and that’s usually a mistake by the previous author. Every language has its own tell-tale signs, and you already know them for Elm, whether you realise it or not.
I don’t agree with elm-format in a bunch of areas; I’ve spent about half my elm dev time with 2-space indentation locally, but since consistency is really important, all code I push or even show to other developers is 4-space indented. If I pair program on something, I turn the 2-space indentation off and pretend like I’m using what everyone else is using. The reason I use 2-space locally is so that I can fit 3 files side-by-side on my screen, which is what I have when I solve merge conflicts.
And finally, humans shouldn’t format code manually, so any automatic format is better than any manual format.
Just got this, a real bargain, and gives you a plenty horizontal space on your desktop:
You know what’s even cheaper? 
Modifying a constant in an open source project. Also, I can’t really carry an external monitor with me everywhere 
1 Like
The discussion of formatting is inevitably one that invites a lot of bikeshedding; let’s not go there.
Coding habits are never about strict rules, but about choices and consequences.
If you have a strong opinion about how Elm’s formatter works, I’d suggest you watch this first:
I think it explains in great detail why Elm’s formatter prefers vertical space over horizontal space, and the advantages/drawbacks this has over making long horizontal lines.
4 Likes
Kevlin Henney makes some good points. One of things I love about elm-format is that when lines start to get too long, usually its just a question of inserting a single carriage return somewhere then re-formatting, and this is usually enough to tell it that you want to turn a horizontal list into a vertical one, and it will insert a load more newlines for you.
I wonder, could it even be combined with Walder’s Prettier Printer (https://package.elm-lang.org/packages/the-sett/elm-pretty-printer/latest/) to automatically switch to a vertical arrangemnt when lines get too long?
2 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.