editor-plugins VS elm-format

There are a handful of plugins and extension for different editors, the majority of which can be found on an officially updated list within the Elm organization on Github. My editor of choice is VS Code, and the VS Code extension for Elm is an excellent tool for writing in Elm. It provides details on errors when saving, references to where a particular function or value is utilized, and access to function documentation on hover

Keep in mind for the pipes, many in Elm, whether they’re using elm-format or not, will break the pipes to a different line in case there are many of them. For some, they find this more readable (I’m in that group). Let’s show an example of that using the same pattern to design a Paginator, the row of numbered buttons that allow you to move between pages of data.

9ᵗʰ - Aaron VonderHaar releases a new version of elm-format.

Unlike Javascript, Elm has an official Style Guide for how Elm code should be structured. In addition, some formatting is built into the language itself, such as requiring indents of four spaces. This removes a major point of contention within teams. In addition, the community has put together a wonderful tool called elm-format. Similar to Prettier, this utility can be used to ensure that all Elm code matches the official style guide. Unlike Prettier, there is no custom configuration, meaning once again that your team can focus on writing code instead of what kind of quotes to use.

Regarding user experience and tooling, I'd suggest you use an editor that is compatible with the elm language server: https://github.com/elm-tooling/elm-language-server VSCode is a good default choice. You'll also be interested in other toolings. elm-json (https://github.com/zwilias/elm-json) is great to simply install and uninstall dependencies. elm-format (https://github.com/avh4/elm-format) is a must since most active people in the community use it, and simply viewing your code being moved around on save is a good sign that you wrote something with a good syntax.

Take for example the debate about 2 vs 4 spaces. People often (but not always) have very strong opinions about this, yet it is clear that this formatting choice will probably not be the dominant factor in the success of a project. A quick google search also reveals no scientific research in this field. Concerning surveys, I found this interesting (from a survey on 2 vs 4 spaces in elm-format) as one datapoint: