elm-format

elm-format

We discuss the core features and philosophy of elm-format, as well as some hidden productivity tricks for getting more out of it.

PublishedFebruary 1, 2021

Episode#23

elm-format
prettier
gofmt, the built-in Go formatting tool
Some discussion of IntelliJ trailing whitespace issues
elm-format editor integrations table
elm-tooling
elm-tooling Elm Radio episode
Jeroen's elm-format tips tweet
NoExposingEverything rule
Discussion about single-line conditionals
The original Elm style guide
Join lines (J in vim, also available with intellij keybindings)

Transcript

Hello Jeroen. Hello Dillon. How are you doing today? I'm doing very good. How about you?

I'm doing well and I'm ready to take on this topic which I think this episode might have

a bit of a unique format. This sounds so bad. You want to tell people what's going on today?

Well, I think you pretty much did. Today we're going to talk about Elm format, if you didn't

already guess it from just what Dillon said and from the title. I'm surprised that we

didn't talk about this before actually because it's such a unique and fundamental tool to

Elm in my opinion. Yeah, it's a little bit like water to a fish.

It's omnipresent and you rely on it heavily but you don't always think about it because

it's just there and it's just part of how you think of writing. For me, it's part of

writing Elm. I was actually pairing with someone the other day who didn't have Elm format set

up on their machine and in their editor and it was very interesting. It was actually writing

some 0.18 code. The IntelliJ plug in wasn't set up to work with Elm 0.18 and if you set

it up, it had all these red squigglies. He just had it turned off and it's really strange

trying to write Elm code. In my mind, it's like writing Elm somehow without the compiler

where it's like, how do I know it works? If I don't have syntax highlighting, if things

don't snap into place when I run Elm format and if I don't get compiler errors, it's completely

foreign to me and it feels wrong in my head.

Here let's go over what Elm format is for the few people who don't know what it is.

Elm format is a code formatter for the Elm language. It's made by Aaron Vonderhaar. What

it does is it takes all the Elm files on your project and it formats them in a reasonably

predefined way. It's made configuration. It has no configuration that you can set.

Which is an intentional philosophy.

With that in mind, all Elm code will look very similar. You can go from one project

to another. The styling will be very similar. That is very nice.

I would say for people who may be new to Elm or the Elm format tool, one of the things

that comes up for beginners or people who are new to the community is, how do I change

the indentation level? I want it to use two spaces instead of four spaces. The Elm styling

is very white space heavy to what a lot of people are used to.

There are white space and empty lines.

I believe there are two empty lines separating each top level definition.

Unless there are comments in between. In which case there are three lines above and two lines

under the comment. So that's six lines.

Good trivia. It's a very generous white space. To some people that feels off, but you get

so used to it as an Elm developer. It just is what Elm looks like.

Let's talk about that for a second. To somebody who is coming to Elm and is asking, how do

I set these configuration options? As with many things in Elm, it's sort of like, this

is sort of how things are done. If you don't like that, then you might not like Elm. It's

somewhat opinionated. It's a feature that this is what Elm code looks like. It's certainly

something that I've come to appreciate. You don't have to think about it. You don't have

to argue with your team about it. As far as I'm concerned, in general with editor configurations,

I remember in the olden days using these linting tools. This was a common thing that linting

tools used to do.

Yeah, and they still do in some languages.

Right. Yeah, they'll complain about this formatting is not acceptable. In the old days, it was

pretty common for a linting tool to complain that the formatting was incorrect, but not

do anything about it. As far as I'm concerned, I don't care what the formatting is, as long

as a tool just does it for me in an automated way, and I don't have to think about it. That's

what I care about. I'm happy to accept any configuration.

I imagine there would be some settings, well, some choices where it would heavily disagree,

but I find the ones that Elm format chose are very reasonable. Even though if you come

from JavaScript, where the comma goes for lists and arrays, that's a bit off, but I

really like it and I want to do that in JavaScript now too.

I work that I have Predier running on the JavaScript code. It removes all those commas

or it moves it.

Yeah, Predier has taken over in the JavaScript ecosystem with JSON, JavaScript, TypeScript

files. If you're not familiar with that, go check out their site and try it out on your

projects. It's quite nice to work with. It is a slightly different philosophy. It has

a few more configuration options, but it's definitely been inspired by, I think, GoFmt,

Go format was probably the pioneer in these tools. Go was unique in that it was built

into the tooling. Out of the box, you've got a formatter and that just is what Go code

looks like. I imagine the Elm format was inspired by that to some extent and Predier as well,

but it's really taken over and transformed the programming world that formatters are

sort of becoming a standard these days.

I remember arguing, or maybe not arguing, but going back and forth in pull requests

on Ruby code and talking about, hey, we should line up these values with these values. You

have lists that you format into columns and depending on the length of the string in a

particular column, you need to have leading white space in front of these other commas.

People configure their Vim or Emacs setups to have special rules that automatically snap

things into place according to their own rules, which are different than the editor plugins

that other people on the team are using. Then people are taking time to talk about that

on pull requests, which I always found that really, that it took me out of the flow of

writing code when I had to think about formatting.

I think this is a key point for me is I don't want to think about formatting, I want to

think about code. This is one of the, hopefully something that might give some insight to

even people who are familiar with Elm format is one of the principles I think that makes

using Elm format really nice is the principle of the shortest path to valid code. Not even

the shortest path to valid code, but find the shortest path to something that Elm format

will transform into valid code. Basically, I think of it as almost like a Vim grammar

or it's part of my editor.

I'm starting to see what you mean. You mean when you're typing, you try to type as few

as characters as possible on your keyboard and then pressing save in your editor and

then it formats everything nicely.

Exactly. I deliberately want to write as few characters as possible. My goal is not

to try to get it close to Elm syntax on the first try and then hopefully Elm format doesn't

do its job. I almost consider it a failing on my part if Elm format doesn't have a lot

of work to do because it means that I've failed to efficiently express the code I want to.

That's my goal. I want the flow of code where I'm just thinking at a high level in terms

of the AST and having it interpret that and do some of the heavy lifting for me. For example,

the Elm format will format your lists if they're on multiple lines with a leading comma, which

a lot of people are not used to. You grow to love it. You don't need to put any

spaces between items in a list at all. You don't need to put new lines between items

in a multi line list. If you have a list that's spread across multiple lines. This is one

thing that even Elm format users may not be aware of. A lot of formatting tools are based

on line length and they'll start to break the line at a specific line length.

That is one of the configurations that's prettier allows you to set for instance.

It right so if you shorten the line or lengthen the line, it'll start to snap it back to one

line or multiple lines. Elm format doesn't work that way. It has multi line mode and

single line mode. If you have a list that's written out all on one line with any amount

of white space between the commas, but it's all on one line, then Elm format will consider

that to be single line mode for that list and it will clean it up and normalize the

white space with its formatting rules all on single line mode in one line. As soon as

you have a single new line in that list, it considers it multi line mode. It doesn't matter

if you have 100 items in the list and a single new line, it considers that to be multi line

mode. This economy of typing principle that I have for using Elm format, if you have a

single new line, what's the point in writing another new line in that list? If you know

it's already in multi line mode because there is a new line and you add a new item to the

list, all you need is to say comma new list item. You don't need a new line. You don't

If you think that your list is way too big and it's currently on a single line, if you

want to put it on several lines, you only have to press the enter key once and then

control save or command save and then it will format it for you. You don't have to put all

the indentation right or add all the new lines, which would be annoying if you have a hundred.

It just does that with one enter and control save.

Yeah. Also, another part of this is when it formats, you know that the syntax is valid.

You know you don't have a syntax or you know you don't have a missing paren or square bracket

or whatever it may be. I use that as part of my feedback loop that I know I'm keeping

my syntax valid along the way. When you are intentionally writing minimal syntax to get

Elm Format to understand your code and format it the correct way, then that gives you that

additional benefit that you're going to see a change that lets you know, oh, it's valid.

Yeah. I use that trick all the time too. I don't rely on the editor to tell me, hey,

there's a syntax error. Although it does help me to find it when I have one. But yeah, that

is a really good check to get in your fingers. So we'll go more into the nitty gritty details

and tricks of how to use it and how to take advantage of Elm Format because it's an awesome

tool that you actually need to learn in a way to use it well.

Yes, exactly. Yeah. There are some hidden Easter eggs that a lot of people who use it

every day might not know about.

Yeah. And we'll go into that detail later. But why would someone start using Elm Format?

So as we said, it can help you write code, but for me, the biggest advantage, and that

is the one that you will see advertised in other tools like Predire, is that it will

stop the conversations around code style. So as you said before, do a pull request.

You don't want to think about code styles. I've worked in open source projects where

the only feedback I got was, this is great, but can you put this on the next line? I was

like, yeah, sure, no problem. But not having to do that would have taken the pull request

one less day to merge because of time zone differences or something.

Right. And it focuses your energy in another place. Maybe you notice something else when

you're not distracted by the formatting.

I think there was a time in my career where I was mostly looking at styling issues when

doing code reviews. That's not a good thing. Now I'm looking at other things, still not

looking at the grand picture, but there's an improvement to where I should focus my

energy doing code review.

Yeah, reducing the noise of those things really can change how you interpret what's going

on because you're not even thinking about formatting. You look at Elm code and you're

thinking, is this formatted with Elm format or not? And if it's formatted with Elm format,

then you're no longer thinking about formatting.

Yeah, you don't have those stray thoughts when you're working on a code basin. Like,

hey, I should probably reformat this code in a different way. Those thoughts don't happen

anymore when you have a code formatter. So that's another advantage.

Yeah. And you also know that the structure and indentation level is going to be reflected.

Now I mean, to a certain extent, Elm has that built in because it does have significant

white space in certain areas with indentation, like case statements, but not with parens

and things like that.

I think it's only for case statements where it's very...

Case statements, maybe if statements too, I can't remember.

No, not if statements.

No, okay. But it is white space sensitive for let's also. Let's are also white space

sensitive in certain...

Elm or Elm format?

If you have a...

You need the declarations to be indented the same way.

Exactly. Yeah. So Elm at the language level enforces some of those sort of... I mean,

this is I think that Evan got this philosophy from Guido van Rassum of Python that the structure

of the code and the visual of the code should reflect the semantics of the code so that

you don't have the possibility that there's a mismatch where it appears that something

is indented at this level, but it's actually not.

Now I would argue that a white space significant language like that actually becomes less...

Actually having significant white space becomes less useful as a feature when you have a nice

formatter and in a certain sense, the formatter becomes harder to work with when you have

significant white space because if you have things like brackets indicating the scope

of if statements and switch statements, case statements, then the formatter doesn't have

to look at white space to figure out what's going on there. It can just say, oh, the scope

is clear. The curly braces determine the scope of this case statement. So I know exactly

how to indent it. So I actually kind of think that would be easier to work with from an

editor experience. And I'm sure it would make Aaron's job as the author of Elm Format easier

too. But the fact that you know that the white space and indentation isn't going to mislead

you about the scope of what you're looking at is definitely a feature wherever that comes

from, whether it's the language or the formatter.

So as we said before, Elm Format gives very white space and empty line heavy code. A lot

of people say that one of the reasons why it does that is for git diffs, which I think

is true, which I don't know if it's a happy accident or if it was, I don't know if the

intent was to make the code more readable by making separate things more separate visually

and whether git diffs are a nice side benefit of that or whether that was the intent. But

you do get better git diffs because things are further apart. Git makes them different,

considers them different. So you get a lot less things that look like they changed, but

Yeah. And having things formatted across multiple lines helps with that too. So if you have

a list with five items or a record with five items in general, you can have Elm Format

put its single line formatting mode on a record or a list with five items. But as far as git

diffs go, now if you change a single field in that five item record or change a single

item in that five item list, your git diff is harder to parse because it said this one

big line has changed instead of this one small precision change.

So in general, I know a lot of people recommend... Actually, does Elm Format? Elm Format does

allow you to have record definitions on a single line. You can do type alias for a record

on a single line, although it's actually not... You can't actually do it on a single line,

right? You can do it on two lines.

Two lines, yeah. Plus white space.

Right. Type alias record name equals new line indentation curly braces record definition.

That's the smallest one it will allow you to do, but it will allow you to do that actual

record definition on a single line.

Yeah. That was actually one of the linting rules in Elm Analyze where it says, hey, no

I remember that.

No single... Sorry. No single... Yeah. No records with multiple fields on one line.

Exactly. Exactly. Yep. That's right. Yeah. And in some cases, it's nice to just, in preparation

for adding an item to a record or a list, it can be nice to just start with the new

line formatting, even though it only has a single item. So sometimes I find myself doing

that where you can say like type alias record equals new line indentation open curly brace

a single field new line closing curly brace. That would be a valid multi line mode for

a single field record. And sometimes that's nice for diffs and adding things to it because

once you add something to it, you don't need to change it to multi line mode because it's

There's another reason why I tried to have the ending curly brace on the separate line

is so that it makes it very clear that this record only has one field because if the opening

and the curly braces are on different lines, then you know that Elm format will make one

field, one line for every field. So if it's only in two lines, you know that it only has

So it's easier for your brain to process it's a single field. That's a great point.

Yeah, but if it was all in one line, then you would have to read through it. And then

you will find out whether yes or not, it would have more fields.

Yeah, that's a good point. Yeah. So I think this is an important point that even though

Elm format doesn't have configuration options, it is a modal formatter. And sometimes starting

with multi line mode can be a technique that helps you reduce churn. And that's that's

one of the things that I look for in the way that I format my code is to reduce churn.

I don't want I don't want something to introduce diff noise where I didn't change it. For example,

when you go from, you know, single line mode to multi line mode in a record when you add

a field, I don't want there to be noise around the closing curly part. And if it's already

in multi line mode, there will be no diff noise around the closing curly going from

the same line to a different line. There will just be a new line. That's the new field.

Yeah, that's actually the reason why the format for let in expressions changed. And I think

you remember that at some point, I don't know which version, but Elm formats indented whatever

was in the in section of let in expression. Right. I do remember that. Yeah. Yeah. So

the expression, the result expression of the let in variable, let in block, sorry, would

be as indented as all the variables. But the problem was that if you added a let in some

let clauses, then everything would be indented and that would not make for a very good get

diff. That was, I think, the main reasoning behind it. So now, yeah, the body is as indented

as if you did not have let clauses. Yeah, avoiding churn is it's one of those like sort

of quality of life things that I think just makes it reduces the resistance a little bit

when you're writing code and makes things a little smoother. I will say one thing that

I've always wished the Elm syntax supported is so, you know, I mean, languages that have

like a different formatting for commas would allow trailing commas, you know, like in JavaScript,

you can have an object or a list with trailing commas or yeah, yeah, objects and lists can

have trailing commas, meaning that, yeah, the last item in the list can have a comma

after it, even though there's nothing after that last item. Because what that means is

you add a new list item and there's no well, there's no list noise that you're adding it

or removing a comma. If you want to reorder the items, then you don't have to like change,

make sure you add a comma in the thing that moved up that didn't have a trailing comma

and then remove the comma in the place that needs to remove the comma. It just, there's

just this churn and this little resistance to changing things and having diffs. And so

I find that really nice and TypeScript allows in type definitions, if you like enumerate

types or if you're, if you're doing a union type, you can, you separate the union variants

with the pipe operator like you do in an Elm custom type, but you can have a leading pipe.

And so what it looks like is, you know, type, type name equals, and then every single line

underneath that is pipe, type, pipe, type, pipe, type. Whereas an Elm, it looks like

type, my type, new line equals variant, new line, pipe, variant, new line, pipe, variant.

So there's this asymmetry and moving it would create resistance and diff noise.

Yeah. Yeah. I don't know how I feel about that. I feel like it's an okay trade off,

but maybe I'm just too used to it, but same thing for the, the start of a list of a start

Yeah. I definitely know that I prefer that it's not like a huge deal, but I definitely

know that I would prefer to work that way if I could, but that said it's not, not the

end of the world.

I think I would probably get used more used to that is especially as, as you said, it

would remove some churn and I would probably, and I would probably stop having to think

about it because my former owner would have handled that for me.

Yes. And just like moving things in your editor, reordering items in a list or the definitions

in a record or custom type variants, there's just that little bit of resistance. And I

I'm all about like removing those little like tiny pieces of resistance. I think that that

adds up to something that's greater than the sum of its parts.

Because Elm formats enforces one code style for all Elm projects that use Elm format,

but that it's like most Elm code basis. Yeah. The only configuration that you can choose

is whether you do single line or multi line expressions. The result of that is that you

can do some nice tricks. For instance, like if you have a record and you want to know

where a field is being set or updated, what you can do is say a field name space equals

and search for that string because you can only change a record field or set it in a

place where that exact syntax is set because that is how Elm format does it every time

for update or for setting of initial set or updating in a regular update expression.

So I find that sometimes more useful than whatever my ID gives me, depending on the

use case. And yeah, those kinds of little tricks. Like I know how to look through my

code base for finding a type. It's always type space, the name of my type.

Exactly. Yeah. Stuff like that. Yes, I totally agree. Yeah. And if you're looking for a type

annotation, you can search for top level value like function or value space colon because

it's always going to start with that if there is a type annotation.

I remember working in a like JavaScript projects where we didn't have a code formatter at the

time and I was looking for some piece of code or trying to find where something could have

been used and was looking for a specific pattern, like I don't know, some object fields, sorry,

like calling a method on a property. So it would be something like blah, blah, blah,

dot function name, parents. And I would look for dots that function and open parems. And

I remember finding after the fact that in some places people added a space between the

open parents. So I didn't find all those cases and therefore I probably introduced a bug.

Yes. So if you have something that always looks the same everywhere, it makes it so

much easier to find things in there. Yeah, I totally agree. And it does, when you're

looking for those things, it does help to know this small set of tricks that we've talked

about, which you can think of as the configuration options to Elm format. They're not options

that you configure through a configuration file. They're configured by having a new line

or not in a certain context. So when people are trying out Elm, they're not very used

to the syntax and they might say, oh, it's ugly. Yeah, I don't want to use that Elm format

because it makes the code too white spacey or I don't want single line ifs. What would

you tell them? Like, why should you use it actually? I mean, to me, it's, you know, as

I said earlier, even if I didn't agree with the decisions for the formatting rules or

if they weren't my personal preferences, which by and large, I do really like and have come

to really appreciate the design decisions for the formatting style. But even if I didn't,

I would accept that trade off that, okay, like, cause to me, the main thing is I don't

want to think about it. I don't want to talk about it. Don't talk to me about how you don't

like my style. Let's agree on an automation tool for it and then do it. And that's the

important thing to me. So that's the main thing. There's also the fact that, you know,

you can go to most, the vast majority of Elm code bases and expect it to be formatted in

that way. And also you can, you can tell pretty quickly if something is using Elm format or

not just cause your eyes get so used to seeing that format. So I think there are just so

many benefits that come from going in on Elm format that I happily make those trade offs.

Even if there are things that you're sacrificing, even if I didn't like those style choices,

I would still happily make that trade off. So I've talked to people who don't like prettier,

for instance, for their JavaScript code and their reasoning was like, it makes the code

pretty ugly, which is why it's called prettier, pretty ugly. Yeah, maybe. And I told them

like, yeah, come on. It's worth it because of all the reasons you just said. And then

he showed me some code, which was, which went through prettier and I was like, yep, you're

right. That's ugly. Because the thing is, JavaScript is a very complex language in the

sense that there's so many features and when you have plenty of features, you can arrange

them, you can combine them. So there will be cases where the code will be ugly because

there's so many possibilities and ever growing as well. TC39 committee is adding new features

left to right, which, you know, it has pros and cons, but that's one of the cons. But

in Elm, the language is relatively very simple, relatively to JavaScript. So there are no,

not a myriad of ways you can combine expressions. There will be cases where it can be kind of

very indented for instance, but I'm pretty happy with all the combinations that we have

currently. I think that's a really good point. And also as far as like overly indented code

goes, you could argue that that's a feature that you see that, that you can't hide the

actual complexity that you've introduced by deep nesting. So feeling that pain early is

actually a good thing. I want to feel that pain of deeply nesting things. And that's

one of the things with prettier that I've, I've enjoyed over just writing, writing it

by hand. I like knowing that it's going to reflect the actual structure of my code and

that I'm not being misled by the white space, that the white space isn't lying to me about

the semantics and the scope that I'm in. So what you mean is when you, when your code

is very indented, that's one sign, one smell that tells you, Hey, you should probably extract

this into a function or a constant or something. Right. And also just in terms of parsing the

code, because it happens all the time when, when I'm getting into callbacks with, you

know, deeply nested callbacks in JavaScript code or something like that. But for one thing,

you want to feel the pain that, Hey, this actually is introducing complexity and maybe

you should think about changing it. But also you want to know what scope you're in and

that you're not being lied to by the indentation that you wrote. So it gives me more confidence

about that. Yeah. I can imagine a colleague who says, Hmm, I need to add some indentation,

but I will not intend the code just so it doesn't look too ugly, but then something

where it shouldn't be. Exactly. Yeah. Yeah. I think that that's a huge benefit of using

automatic formatters. Also like this whole thing about, you know, should you have semi

colons in JavaScript code or not? I really don't care. I care if I need to type it or

not. And I don't type it with prettier. I actually just don't really configure prettier. And the

default setting is that it uses semi cons and that's fine with me. I really don't care.

I really don't care if it includes semi colons or not. You decide as a community what you

think is a good idea because of certain gotchas. If you don't include a semi colon, fine. I

really don't care at all as long as I don't have to type them and I don't have to worry

about being inconsistent, typing them someplace or another. I care about what my fingers are

doing and, and my ability to read the code. Semi cons don't really get in my way of reading

code. It's fine. So that's really what I care about. Yeah. Did you know that pretty, when

it launched, it didn't have that option for semi colons or not? It was that makes sense.

And it, the default or the only choice was to have semi cons. Yeah. Yeah. I know that

they attempted to start it out with a more zero configuration philosophy and then started

to sort of diverge from that over time. Yeah. They didn't hold the grounds. Yeah. Huge shout

out to Aaron for holding his ground and having state configuration. Yes, I agree. I think

it's a huge feature. Zero configuration is itself a feature, I think. And especially

for the author because you don't have to handle that configuration. Although it is, I'm sure

a burden to have to make choices to sort of make different groups happy who may have different

style preferences, but you know, thank you for doing that, Aaron. Yeah. In my mind, the,

the reason why it works so well for Elm format to have no configurations is because Elm format

is was there pretty early on in the, in the life of Elm. So pretty early came out after

like 22 years of JavaScript existing. So people have had careers where they were used to a

code style or maybe it grew, but they, they started to get entrenched. Is that, can you

say that? In a code style. And then it's very hard to, to go out of that code style, even

if there's a formatter for doing it all for you. So people who worked with JavaScript

for 20 years and without semicolons, like I can get why they didn't, wouldn't want a

formatter. Especially if there are plenty of other issues related to the code style.

But yeah, Elm format came up pretty early on. And for a lot of people, it was a new

language where they started using Elm along with the formatter. So yeah, it kind of helped

them and it you learned Elm at the same time as you learned the Elm syntax and indentation

and code style. So I think, I think that's a huge boost to Elm formats adoption and that's

why it's used all over the place now. That's, that's a great point. Yeah, I agree. I think

the adoption and widespread use is also a feature. Oh yeah. Yeah. If Elm format was

not as adopted. Yeah. That would be very different. Yes. Yeah. I'm very happy that there's no two

versions of Elm format. Elm format and Elm alternative version. Yeah. I'm very happy

about that. Yeah. Yeah. It's the defacto standard and it's yeah, it's a great asset to the community.

So there's one case where I could imagine that people would build an alternative to

Elm format. I recently talked to someone who was like, who was blind and he used a screen

reader for his code, which I just find impressive. It's very impressive. Yeah. Yeah. And the

problem was there, the empty lines and the buttload of empty lines that we have with

Elm format, they were actually really painful for them to work with. And it made it very

hard for them to follow indentation. And yeah, I can imagine hearing A equals B new line,

new line, new line, foo equals. Yeah. I don't know. But I can, that's how I imagine it.

And I can imagine that's painful. So I wouldn't be surprised that if some people had a blind

person or someone who needed screen reader on their team and they would fork Elm formats

for their use case to afford to have less empty lines. I could imagine that, but. That's

a really good point. I wasn't aware of that, but that is, yeah. I mean, it seems like it

would be difficult enough. I've seen like a video of someone programming with a screen

reader before and it is very impressive and difficult. I mean, imagine like navigating

code and, but yeah, I mean, it's hard enough as it is. So anything that eases that would

be great. Yeah. So if you do have such a person on your team, maybe think twice about using

Elm format or try to make their life easier one way or another. There's also some guttures

about Elm format that you sometimes need to know. So I'm writing Elm review rules as some

of you may know, and sometimes I need to work with white space issues. So I need to write

a block of Elm code in a string with white space at the end. The thing is, yeah, and

do it in a multi line string. The thing is Elm format removes that white space at the

end. It trims it. So that's one thing you need to know is that if you have multi lines,

it does change the value of the multi line strings by removing the white space at the

end. So if you have. Inside of the string? Inside of the triple

quoted string? Yeah. Really? Yeah. That's surprising. I didn't know about that. I guess

the use case for me has never come up of having, no, you can have like indentation. Are you

sure about that? It might actually be my editor. I haven't checked it. Could be my editor,

but that would be, no, that might not be that surprising actually. Oh, I need to look into

this right now. I just tried it out in IntelliJ with Elm format and I saw it format and it

did not remove the trailing white space within a triple quoted string. It is IntelliJ that

does it. My bad. Oh, it's IntelliJ. It's IntelliJ. It's IntelliJ itself? Yeah. Yeah. Did you

just Google and find something about IntelliJ doing that? No, but I've just tried it out.

Probably as right as I was before when I said it was Elm formats issue. Hmm. We may need

to look into this a little bit more. Yeah. Because I thought that it preserved pretty

faithfully what was in the triple quoted strings. It does like change if you have a backslash

N, it will turn that into a literal new line and it does a couple of things in the context

of normalizing a triple quoted string, but Elm format does it right. It doesn't remove

the white space at the end. But the thing is if you do try to trick Elm formats like

by having a unicode character for white space, then Elm format is trying to be too smart

and you replace it by a white space, which IntelliJ then removes. Oh, that's a good gotcha.

Yeah. So yeah, in that case I had to do string concatenation or replace the white space by

a stupid character like a dollar and do string.replace. That was annoying to find out. So it looks

like there are some IntelliJ settings for strip trailing white space. Yeah. Well, I

do want that, but I don't want it in some of my strings. Of course. Yeah. Yeah. No,

that's seems like a bug. There may be some bugs around that too. Maybe we can find some

links. I found like a little stack overflow thread about this as recent as 2020. So let's

gather a couple of resources about this topic and share them. But it seems like Elm format

is off the hook for this problem. It is off the hook. Problem is an editor issue, not

Elm format. So good. I'm very sorry, Aaron. The other issues that are raised in the repo

are still valid. Please look at them. Yeah. So while we're talking about multi line strings,

there are some helpful things it does. Like if you have, like I think if you have like

a literal tab, won't it turn that, or if you have a, like a backslash T, it turns that

into a literal tab. And if you have a backslash N, it turns that into a literal new line.

So it's opinionated about like regular strings in Elm. It will not use the literal tab. It

will use backslash T and triple quoted strings. It will use the literal. Yeah. It doesn't

do it for backslash T. It does it for backslash N. Only for backslash N. Yep. Okay. So it

preserves backslash T, which is probably good because visually it's harder to pick that

out. Yeah, probably. And I think it does the same for, I think in general for Unicode characters,

it normalizes them. Right? Yeah. I'm guessing there's a range where it does, where it applies

that and another range where it doesn't, but yeah. So in general, like one trick that I

sometimes use, Elm format is really interesting because it's a formatter, but you also sort

of use it as a tool to perform certain transformations. So like if you have a regular Elm string with

new lines in it, you can just add two quotes on either side of the string and turn it into

a triple string and it'll turn them into literal new lines, which is a nice feature. So if

that's what you wanted to, yeah. Well, yeah. I mean, I think that's a reasonable opinion

that it should, in the triple quoted string, it should visually look like a new line and

you shouldn't be able to mix backslash N with a literal new line. That would cause problems.

Yeah. Yeah. So I like that about it. It's worth noting that IntelliJ has a built in

feature which Joni Gibbs contributed, which you can convert a regular string to a triple

quoted string and it sort of performs some of those normalizations as well. So you don't

necessarily have to do it using that Elm format trick, but you can if you want to.

So we've talked about it a lot, but like the main thing you need to do when you use Elm

formats, in my opinion, is to enable it in your editor. If you already haven't, do it.

The Elm formats project ReadMe explains how to enable it in a lot of different editors.

Yeah. Yeah. You can look at that. We'll link to that, but it's basically just a table that

has which editors have an integration with Elm format and the instructions to set it

up. I would actually add, you said that basically what you need to do to use Elm format is to

configure it with your editor. I would add one other thing. In my opinion, you're not

really using Elm format unless you're running it in your CI because that's the central source

of truth. So for example, it's possible that you could have different Elm format versions

that people have set up with different editors. They could be pointing to their globally installed

Elm format version rather than a locally installed one in the project. There are all sorts of

things that could happen like that. So I would say that it's really important that your build

be the central source of truth for making sure that stuff is formatted so that you don't

ping pong back and forth between formatting with different versions or anything like that.

Yeah. The same thing for Elm review.

Yes. Right. Exactly. Yeah. I mean, I think it's equivalent to having frontend validations,

right? You can validate that somebody is an admin user on the frontend and don't expose

a certain thing in the UI unless you're an admin user, but that's not enough. That's

like helpful as far as user experience goes, but you need to enforce that in the backend

part and it's the same with your build. I would think of the build as the actual source

of truth for enforcing all of those configurations and rules.

And now it's easier than ever to enforce Elm format in your CI because as we've seen with

Elm tooling in the last episode, it's very easy to install and cache and run.

Exactly. Yeah. And that's another, I mean, as we were saying, you could have this issue

of having different Elm format versions and the CI should be the source of truth for which

Elm format version and which files it applies to, but it doesn't hurt and it's a very good

idea to also have a source of truth of which versions you're running for a project using

your package JSON or even better, the Elm tooling CLI, which you can listen to our episode

on that. Yeah. You don't want to check out someone's

branch and then press save and find that Elm format formats are differently. That is really

the scenario that you want to avoid because that will create a lot of noise that we said

we don't want. And then one last sort of caveat here. So

you can run, we didn't mention the actual command, but you can run Elm format with the

dash dash validate flag. And that's what we've been talking about running on the CI. So you

can run Elm format from the terminal rather than your editor. Your editor should be the

primary place you're using it. But if you wanted to, you can run it from the command

line and have it modify the files and format them in place. But more often what you'll

want to do from the command line version of Elm format is run the dash dash validate flag.

Yeah. I've run it once in my tests. Yeah. Yeah, exactly. Yeah. So one caveat to that.

And for those wondering, if you also have Elm review, you should run Elm format before

Elm review. That's something that I, the Elm review rules kind of expect the code to be

Elm formatted. That's how widespread Elm format is. And when it fixes something, it will reapply

Elm formats. Yeah. Right. Right. Interesting. Also, if you have generated code, you want

to skip running Elm format dash dash validate on the generated code. I usually like to have

a gen folder and a source folder in my Elm.json source directories. And so you can validate

on your source folder and your tests folder and not validate Elm format in your gen folder,

because as long as it compiles, you're happy. You don't care how it's formatted. What do

you do when you generate code? Do you try to make the code look kind of Elm formatish

or do you run Elm format afterwards? I run Elm format afterwards. I've tried with like

the Elm GraphQL generated code, for example. I tried, but so there are a couple of problems

with that. For one thing, what about different Elm format versions? How do you target those?

So that's a whole rabbit hole and an issue that you can't really solve that properly

and you shouldn't. That doesn't make sense. Well, then why do you run Elm format on it?

Because the user might actually use a different version. No, I run the user version. I'm actually

working to improve that. We talked about it a little bit in our last episode with Simon

Lydell, but I'm currently using NPX to run Elm format, which is not really what I should

be doing. I should be doing more what Elm review does to search for it in the path to

see if Elm tooling is set up and find that version and give different options. No, for

now, at least it does NPX and falls back to the path. To the path. Yeah. And that may

be at some point it should look at the Elm tooling JSON file. Yeah, which it should be

on the path ideally if you're using Elm tooling. So yeah, I mean, but in my opinion, it's sort

of a losing battle to try to automatically generate that code. On a similar note, and

you can also get very complex rules. It would get very sophisticated with particular types

of generated code. But the Elm format is relatively stable, so you wouldn't change all that much

to use Elm formats. But there are some cases that get quite complicated. I try to be relatively

close but not worry about it too much. Also, we sort of talked about the challenges with

formatting when you have a white space sensitive language like Elm. And that actually becomes

a really challenging issue when you're working with editor plugins. So when I've worked on

contributions to the IntelliJ Elm plugin, that is, believe it or not, in many cases,

that's by far the hardest part is getting the formatting right because you have to look

at the content. You can't just throw in some curly braces and say, all right, I'm creating

a new scope, a format or tool, figure it out. If you're adding something to a lead expression,

you have to figure out where to start that indentation. And I find that painful both

for writing automated editor tooling or automated tools to get the formatting right, but also

as a human. That's probably the most painful thing about the experience of typing Elm code

and formatting Elm code in my experience is getting the white space to line up in lead

expressions and case statements.

Yeah, that is probably the biggest, that is probably the hardest problem when you try

to fix a syntax error is trying to line it up. Which one is not lined up? When they're

all lined up, even if the rest is ugly, save and you're good. So it doesn't happen too

often, thankfully, but yeah.

So Jeroen, I think it might be time for our Elm format editing productivity tip section.

Let's do a lightning round. So you've got a really great tweet with a whole bunch of

great tips for sort of like Elm format workflow tips. These are like these little Easter eggs,

these little tricks that you can use to sort of leverage Elm format to have it do more

work for you or to get it to format a particular way. So let's go through a lightning round

and go through these.

Yeah, so a lot of them are about indentation. So unless we talk about case expressions,

we don't, Elm format doesn't really need to know the indentation. It can figure it out

on its own. So if you do A equals one, it will move the one to the new line. But if

the one is even on the next line, at the very beginning, it can figure out that it should

be indented. If you have a single, if you have a case expression with a single pattern,

then you can also handle pretty much everything on its own because there's no mismatch between

indentation between patterns because there's only one pattern.

And by the way, these are habits, just leveraging these little tricks to more efficiently use

Elm format and have it do more work for you and you do less work. They're habits. And

so I highly recommend, look at this tweet, take one of these and try building it in as

a habit. Also, just try things. If you're like, can Elm format handle this input? Just

try it, just save right away and get in the habit of saving more often and notice when

you're typing more than you need to, to get it to format properly and try to do as little

Yeah, I sometimes amuse myself by counting how many keystrokes I type.

Nice Elm format golf.

Yeah, I do type in the white space usually, but that's about it because it still needs

to make sense in my head.

White space costs extra.

It costs only nothing. It's empty.

Tell that to your pinky.

Wait, my pinky?

Did you use your pinky for the space bar?

Yeah, okay. Yeah, I use a pinky for that one. Okay. So there's one very nice thing that

Elm format does and that could help beginners without them even noticing is that Elm format

is smart enough to know when you should use colons or equals in records. So if you do

open curly brackets, B colon one and bracket, and you do that in an expression. Well, that's

a syntax error because you should be using equals instead of colon, but Elm format is

smart enough and it replaces the colon by an equal sign plus adds all the white space

and the indentation. So if you ever do that kind of error, well, Elm format handles it

for you and it does this for the other way around. So if you use equal in type annotation

then or in the type definition, then it uses the colon.

Right, which that's useful for beginners and for experienced Elm programmers who know that

that's the correct syntax, but maybe you copy paste a type alias for a record and you want

to create a literal value or you copy paste a literal value to define a type alias for

a record. Now you don't have to do the extra work. You can just let it figure it out and

you change the types to the right of the colons to concrete values or type annotations depending

on what it needs to be.

Yeah, if you have a lot of fields and the names are too long, then that's a big time

save. Everything is relative, but yeah.

What if it would be an interesting feature. What if Elm format took, so if you say like

if you have type alias and then a record and you say like first colon string, last colon

string, age colon int, and then copy paste that and try to create an instance of that.

What if Elm format changed the strings to empty string and the int to zero? I don't

know. Maybe that's like, maybe that could like cause issues or that's too strong of

an opinion, but I would find that useful for my own workflows because I find myself doing

that all the time where I just like multi select all of the word capital string and

change them to empty string so I can start, so I can get valid syntax and then start entering.

Yeah, that's where it's lying between a code formatter and a dev productivity tool.

Bit blurry, but yeah.

It sort of straddles those two categories, but that's also, by the way, that's another

principle that I try to follow when using Elm format and just in general is try to get

to valid syntax first as soon as possible. Don't like defer, have like a missing current

or curly brace or missing parenthesis or something like that for a long time and then start typing

a bunch of stuff. Do the thing that makes the syntax valid so Elm format is happy and

then start replacing.

Yeah. I very often do like, if I know I need to do a let's expression, I start typing let

a equals something.

And then in, and I want to focus on the let declaration. So what I do is after the in

and type in like one or something and then press save. So at least the syntax is correct,

even though it doesn't compile.

Exactly. I do that as well and I do that also for like modules. If you define a new module,

module foo, you're going to need to define a top level value or top level definition.

So I'll usually just say foo equals one, two, three, just so it's now compiling. And now

I can write the thing I want and then delete that or replace it when I'm ready. But at

least I'm starting with valid syntax.

Those two and three are, you know, they have a cost, right?

Yeah. Let's talk about module definitions. So if you don't have a module definition,

you know, where it says module a exposing blah, blah, blah, then Elm format will generate

one for you. I think by default it will add all the things that you defined in the file

and add them to the exposing clause. If you only have like module main and not exposing

something, exposing something, then it will do the same thing. So if you were...

Even though that's, as far as Elm is concerned, it's invalid syntax to say module main and

then start your module. But as far as Elm format is concerned, it can figure out, okay,

I'll create the exposing clause for you.

Yeah. So if you like to prototype with exposing parents dot dot parents, then once you're

happy, you can remove exposing dot dot and Elm format will add whatever is in your module.

And then you can only, you can go and remove the ones that you don't want to expose.

Exactly. And it's kind of interesting because Elm format can, or Elm review can also do

that for you. The Elm review no exposing all rule can automatically, there's an auto fix

available where you can allow it to find all the top level definitions and expose all of

those explicitly, which is the same thing that Elm format does essentially.

Yeah. No exposing everything. Yeah. Another thing that it will do is like, it's not very

tricky, but yeah. Another thing that it will do is remove duplicates. So if you do exposing

B comma B, then it will show that to just B. You don't need the parents. If you do exposing

B and you have only a single item, it will add the parents and for imports, they all,

it will also remove the duplicate imports. In this case, I think it is trying to be too

smart sometimes. So if you do like import A as B and you have another import A, then

it will remove the imports A. So that changes the behaviors slightly, but it's an easy fix.

So right. Also worth noting that it will alphabetize your import list. So it's deterministic.

I'm so happy about that one. Yeah. It's very nice. I'm also very happy that Elm chose to

have the module names before what is exposed because I've seen so many proposals in ESLint.

I've actually written in ESLint's imported order rule, which was part of my beginnings

with the open source, where we try to order the imports and having just the format and

handle that for us in, I think a pretty reasonable way. That's just a huge time saver. You don't

know how much people want to discuss import order in other languages. I still have issues

open like five years later about, Hey, can we add this sorting order for imports? No,

just leave it alone, please. It's a nice feature. So if you're writing a package with documentation,

or I guess just writing documentation for a module, you can use the module and top level

definition documentation feature, the doc comments, which are open curly dash vertical

bar. So if you use that functionality, Elm format has a few things it does with that.

It will snap the definitions. It associates those with the top level definition you have.

So if you do doc comment and then foo equals one, two, three. Now that comment is not floating

on an island in the middle of nowhere. It's attached to that top level definition of foo,

which is nice for formatting. So if you want to write a little comment describing a function,

you should use that even if you're not doing a package where it would use those docs for

the package. And a lot of your editor tooling will actually, if you hover above an internally

used function and stuff, it will show you the doc comments. So it's a good feature to

leverage for regular Elm applications as well.

In the exposing clause of the module, if you have a documentation for your module and you

have at docs clauses where you say at docs foo comma bar, then Elm format will order

whatever is in your exposing to match the order of that documentation.

Right. And it'll group those on the same line. For anyone who doesn't know, it's like the

at symbol, D O C S space, and then a comma separated list of top level definitions, types,

functions, values. And that's what package Elm package authors use to organize their

docs. If you notice that Elm packages will have like different sections with different

headings and then it'll have the documentation for specific functions and types and values

under those headings. That's how that's organized.

Yeah. And if you have several ones that are not documented, they will all be at the end

of the exposing clause on one line. So you know, oh, these are the ones that are not

exposed. They don't have doc comments. Interesting. So we've got a few more tips from your tips

tweet. Should we go through some more of those? Are there any other highlights? Oh, you sort

of covered it by describing the sort of general techniques. Cool. So that's worth scanning

through. Also, another thing that Elm format will do that people will probably notice from

using it pretty clearly, it will remove unnecessary parens in most cases, but not all.

I think there are plans to make that better. To do it everywhere.

Like one of the places it currently doesn't do it, that maybe there are plans being discussed

for doing is with pipelines. If you have right pipe expressions.

Yeah. In general, it's with operators and there are plans to improve that.

That would be great. Yeah. Cause there are cases where it's just provably equivalent

if you remove the parentheses, but I mean, it is difficult because parentheses can sometimes

mean semantics. Also in terms of workflow, sometimes you put in some parentheses and

you're like, Oh, great. I've got these nice little parentheses that I can start typing

my function calling. And then you like you save and you're like, Oh, the parentheses

are gone. So you have to sort of, or if you're using like IntelliJ with auto saving, you

have to like race to the finish to get in space arguments so that it sees that it needs

parentheses, because if you don't do it within the four second time or whatever the auto

save window is, it'll form at it. So I think it's interesting.

I wouldn't recommend using auto save, especially with a formatter.

I think it's on by default, isn't it? Oh, it's at least not enabled on my machine.

That's a, that's for sure. Oh, maybe. Yeah, maybe not. I'm not sure. Auto save cannot

be disabled completely. Is that an issue? I went, I went to the system settings in IntelliJ

and it literally says auto save cannot be disabled completely with a link. How it works.

Right. So there are probably plenty of things that

M4M1 does and that we don't know that I'm not aware of at least. I know that Aaron hints

that there are being more features to discover. So that's if you want to have fun, either

go through the tests of the project or like try to have fun and discover, Hey, can it

fix this? What happens if I do this? That could be a good five minutes of fun, I guess.

Yeah. I know Aaron's also been doing some live streams on Twitch with working on Elm

format occasionally. And he'll, I know he's been working towards getting it to 1.0 and

he's got like, I mean, it's so stable. It's like, I think of it as a very 1.0 stable tool,

but he's got a few things I know on his list of things he'd like to do before calling it

1.0 officially. I think one of the main ones there is single

online ifs and also patterns for... Oh, interesting. Maybe we can link to those

issues. Yeah, we can do that.

Cool. But yeah, you can go and have fun looking through

the issues to see what people talked about even years ago, when they thought that something

was a good idea. Right. There's an interesting, at this point,

effectively historical document. There's actually in the elmlang.org website, there's a style

guide, which you'll find in the show notes. And it's kind of interesting because I think

it was sort of the precursor to Elm format, sort of laying out principles like this one

says, types, do not be a maniac with indentation. Simplicity will be better in the long run.

And then it's got this example where you have like...

You've aligned with all this white space before the colons in these record types definitions.

And it's like you align all the colons, even though the names of the field names are different

lengths. And it's like, I remember spending time doing that in Ruby and it's such a waste

of time. Just let the formatter have an opinion about it and do it.

Well, there are issues to enable that on Elm format.

Oh, really? Or behind a configuration flag, you know?

But they're pretty recent too, some of them. So yeah, I would really recommend against

that. It can be nice, but it's such a nightmare.

It creates a lot of churn with the diffs. And I think that churn is one of the core

values. I think that Elm format has tried to follow that. And that's just one of the

things I seek in my ideal formatting tools and the way I use those tools.

Yeah. But yeah, if you need to align things based on the size, based on the number of

characters of a variable or even expression on the right, that makes things very complex.

And you will have a lot of white space if you have very short variable names or field

names followed by a very long one. That's just not great, I think.

That said, if Elm format decided to go with that route, then I would probably get used

to it. And I would be fine with that. But that's not what I would advise for.

Another tiny little trick here, workflow trick, is for users who are using Vim or Vim emulation

in their editor, there's a Vim command join lines. I think actually IntelliJ has like

a built in join lines command too, even if you're not using Vim mode.

But in Vim, it's capital J. And that will take the current line you're on and effectively

remove the new line and combine it with the next line with a space. So if you have something

that's in multi line mode, like a record or a list, and you want to turn it into single

line formatting, capital J, capital J, capital J, capital J can be a handy little trick for

getting all those lines onto one line. Although in general, I lean towards multi line formatting

mode more often than not.

There's the same thing in most editors. The shortcut to the i sign was control J. But

that might be just me changing it to control J because that was the way it was in Atom.

But what you can do is select a code block and do that shortcut. And then you only have

to do it once because you know, pressing J multiple times has a cost.

Exactly. That's right. All right. Well, any last tricks that we missed or should we move

on to how to get started?

Yeah, maybe we should talk about how to get started now.

I mean, I think we kind of covered it. We talked about set it up in your CI. We talked

about share a common version in your project, either using npm install dash dash save dev

elm format, or using the elm tooling CLI, which we discussed on a previous episode.

And please integrate it into your editor. Don't just run it in the CLI. It's part of

Oh, and yeah, if you're working on a project and it doesn't use elm format, do talk to

your colleagues about enabling it and make the choice together. I think it's a very good

choice, but you should definitely talk about it with your colleagues.

That's a great point. Also, I've flipped the switch on code bases to elm format them before.

And just to give a brief overview of what that looks like and what I've done there.

I would say that, you know, I think it's best to do it as an atomic step to just have a

single commit that runs elm format across all files and introduces this is important

CI check that will fail the build if it's not formatted properly. So at that point, so

you're going to want, of course, you're going to want sort of team consensus before you

It would be very rude to just do that without talking to your team. And you're also going

to want to just help people get elm format set up and understand what it is and how to

use it in their editors.

You need to make that very simple for everyone to use.

Yeah, exactly. Often you'll want to create like a little intern internal wiki entry for

your company wiki or something like that, that links to like a couple of resources for

your specific setup instructions.

Or even have you like your test suite when it finds that elm format is not has problems.

Like add something in CI saying, hey, this is what you should do now to run elm format.

Right. And then I would recommend doing that as a single atomic change where you run elm

format and add the CI step as a single commit rather than sort of little by little formatting

files and running elm format and having diffs.

Also I recommend not combining code changing commits with elm review application commits.

I mean elm format, but yeah, sorry.

Maybe both. Yeah, maybe in general it's elm format is part of writing elm code, but the

initial step you don't want applying elm format the first time to a file to be the same commit

as writing that writing or changing that code.

And also be aware that it will destroy your git blame.

Yeah. But if you have just a single commit, there are like some git tricks.

Some people use like a destructive history destroying version where it applies elm format.

I don't think that that's a good idea.

Apparently there are ways to have git interpret a certain commit as something to skip over

when you do git blame.

Maybe I'll see if I can find a link and link to that in the show notes.

That'd be useful. I don't know about that either.

But all the more reason to do it as an atomic step with a single commit is just like rather

than having 50 different commits over time in a scattered way where the git blame is

pointing to just do it as a single commit.

Well, if you were curious about elm format, I'm pretty sure your curiosity has been satisfied

And I'm pretty sure that you learned something.

I hope you learned something.

I hope you learned something whether you're new to it or familiar.

And if there's a tip that we missed, please let us know.

Tweet us at elm radio podcast on Twitter.

If you have an additional topic you would like to hear us talk about, then please submit

a question elm dash radio dot com slash question.

And don't forget to rate us and subscribe on Apple podcasts.

Well, Jeroen, until next time.

Until next time.