Elm-format: Configure tab length

[maticzav]

Is it possible to change tab length of beautified code? For example from 4 (i guess it's set to 4) to 3?

[specious]

2 spaces is also very popular. Having an option to change that would be really awesome.

[avh4]

A core goal of elm format is to have a single formating style. Can you provide more details about why allowing different lengths is desirable?

[specious]

A consistent formatting style throughout a project is excellent. Why enforce such a setting universally without providing an option?

Some projects have an .editorconfig file to specify such choices. Perhaps elm-format could be extended to follow what is specified there.

[maticzav]

Many text editors, Atom for example, have the default tab length set to 3. In case you are using a code beautifier with default tab length set to 4, as elm-format in this situation, your code turns into a mess, because of unaligned lines which cause additional errors.

Thought it can be fixed with changing default tab length or specifying tab length for elm-files only, I think it's not the right solution, to set custom tab length for every language you use.

Maybe there could be sth like tab length recognition system behind the scenes, if not config file?

[gdotdesign]

I prefer two spaces so I'm compiling from source, the only change needed for that as far as I can tell is to change the spacesInTab to 2 https://github.com/avh4/elm-format/blob/master/src/Box.hs#L248

[rtfeldman]

See https://github.com/avh4/elm-format/issues/158 for a discussion on why it is important that it never be configurable.

[crazymykl]

I would much rather have a level of configurability a la rustfmt than be ultra-rigid like gofmt.

[Namek]

Tab length

A core goal of elm format is to have a single formating style. Can you provide more details about why allowing different lengths is desirable?

@avh4

There aren't too many Elm users yet, so you may think it's simple to convince them over style.

But no matter what style guide says, some people will fork elm-format, modify tab length and compile it themself. At first, you would think "oh, okay let them do what the want" but in the other hand by forbidding configuration you'll doing the opposite of this statement + break community.

I'm pretty new to Elm, played with it few days and I see that in current state that's completely unreasonable to have so called "style guide" while standard library not following rules written into elm-format.

@rtfeldman whole topic #158 tells me exactly that fact - people want it to be variously different. While I'm not against "4", telling other people that "4" is the best number for them is simply rude IMHO. I don't want to start flame war but please understand that people have reasons.

@avh4 This comment https://github.com/avh4/elm-format/issues/158#issuecomment-219262937 tells me basically _nothing_. You showed some percentages without numbers as a good statistical social proof, closed the topic and gone away.

But what I'm mumbling for is not just tab length.

Not only tab length!

Honestly, I believe there's much more to configure than tab length. Consider this:

        newDayCount =
            weekCount * daysPerWeek

        diffDayCount =
            newDayCount - (Array.length days)
    in

I don't know about your job but mine is about reading a lot of code, not only writing it. Thus, I would prefer less scrolling while analyzing already written stuff:

        newDayCount = weekCount * daysPerWeek
        diffDayCount = newDayCount - (Array.length days)
    in

^ this is just better to me in larger scale. Too great number of newlines is a false positive to better legibility.

But hey, some people would desire seeing this - aligning =s are minimum 2 spaces on both sides around them:

        newDayCount   =  weekCount * daysPerWeek
        diffDayCount  =  newDayCount - (Array.length days)
    in

But there's more I don't like, just look at it:

daysPerWeek =
    7


defaultCalorific =
    2100


defaultWeekCount =
    4

^ 3 lines would be enough, really.

And giving 2 empty lines between definitions? _Why not 1_?

Another thing, let's cite some part of "style guide" (about Line Length):

Keep it under 80 characters. Going over is not the end of the world, but _consider_ refactoring before you decide a line really must be longer.

consider is big word here. 80 is a small number. That's just an another opinion of mine.

Summary

Configuration is what we want. Non-modifiable rules over style are not acceptable because things like that divide community abandoning some efforts like yours. Please step back in history, look at all other programming languages and count successes about style guides that you're trying to achieve here. Just to note C++, Java, even C# and I won't even mention JavaScript or TypeScript (oh, I did).

And the last thing - don't get me as "yadda yadda he's complaining" but as a strong opinion handler, which I believe many people are but don't want to spend time on writing same thoughts. And thank you for all your effort @avh4 @rtfeldman

[rtfeldman]

I'm pretty new to Elm, played with it few days and I see that in current state that's completely unreasonable to have so called "style guide" while standard library not following rules written into elm-format.

This is because Evan doesn't want to rewrite the official docs every time elm-format evolves on the way to a stable 1.0 release. Considering how many docs are involved, I would not label that decision "completely unreasonable." 😉

Configuration is what we want.

As @avh4 noted, a core goal of elm-format is to have a single formatting style.

Just to be super clear on this, you fundamentally disagree with this core goal, yeah?

[crazymykl]

The official style guide optimizes for minimal diff-noise. Some people would much rather optimize for concision when it serves readability. Letting each project make that decision for themselves seems nice.

[Namek]

Just to be super clear on this, you fundamentally disagree with this core goal, yeah?

@rtfeldman Thank you for your response. To be super clear, it doesn't matter.

The official style guide optimizes for minimal diff-noise. Some people would much rather optimize for concision when it serves readability. Letting each project make that decision for themselves nice.

@crazymykl That's huge what you just wrote!

Besides this, I have nothing else to add. Just wanted to make a small place to vote.

[Janiczek]

Shouldn't this conversation then turn from "change elm-format to allow for two styles" to "change official style guide"? Because it seems to me elm-format is supposed to reflect the official style guide.

[bgourlie]

Shouldn't this conversation then turn from "change elm-format to allow for two styles" to "change official style guide"?

Yes, or perhaps even "Should a language endorse/enforce a single style." IMO, the answer is yes.

Languages are, among other things, a collection of idioms. The more idiomatic a language can be made, the easier it is to dive into other people's code.

Also: It's just another thing that can be universally automated and verified.

[Namek]

Languages are, among other things, a collection of idioms. The more idiomatic a language can be made, the easier it is to dive into other people's code.

Ideally, there are no wars, ill people and deaths caused by starvation. In practice, I've just found 5 forks of this project changing spacing 4 -> 2.

[bgourlie]

I've just found 5 forks of this project changing spacing 4 -> 2.

How many forks of gofmt are there?

[crazymykl]

I want this issue to remain "make elm-format configurable", not "change the official styleguide".

[mattjbray]

We can learn from other communities that have already been through this.

For example, Haskell has hindent. The author of hindent recently removed support for configurable styles.

[crazymykl]

hindent is not a blessed part of the language's canon toolchain, though. And there are other formatters available for Haskell that do support configuration.

I would much rather see elm-format go the way of rustfmt, not gofmt.

[szubtsovskiy]

+1 for configurable tab length. Four spaces is just too much. With two spaces my code is more compact and nice. Having stable tab length across the project will serve the purpose of reducing amount of lines in a diff, will keep same code style and will not have real impact on single formatting style of all projects in the community. People (including myself) are going to fork this project, change tab length and then use own binary.

elm-format is a great tool which does great job. Being too flexible is definitely not a right choice but to disallow any flexibility is also a bad option.

[rtfeldman]

At the very beginning of this thread @avh4 posted: (emphasis mine)

A core goal of elm format is to have a single formating style. Can you provide more details about why allowing different lengths is desirable?

Responses

Here have been the responses:

Why enforce such a setting universally without providing an option?

Many text editors, Atom for example, have the default tab length set to 3.

I prefer two spaces

I would much rather have a level of configurability

While I'm not against "4", telling other people that "4" is the best number for them is simply rude IMHO.

The official style guide optimizes for minimal diff-noise. Some people would much rather optimize for concision when it serves readability.

With two spaces my code is more compact and nice.

Summary of the responses:

• "Editors may have a different default tab length."
• "Some people want less whitespace."
• "Configurable is innately better because people have different preferences."

Conclusion

The evidence is clear that:

1. There does not exist one single style that makes 100% of people happy.
2. These debates will never end. We have seen that not only here, in this thread and in others, but also in the JS ecosystem with the endless debates about semicolons and linter rules.

Because of 1, if elm-format were configurable, a large number of teams (not 100%, but a lot of them) will end up having members with differing style preferences. Because of 2, these teams now have an additional burden on top of all the software development they need to do: debating configuration.

I would argue that this is not time well spent, but it is time that will be spent (due to human nature, it seems) if it can be spent. One need only scroll up for evidence of this.

In conclusion, making elm-format configurable makes teams using it indisputably less productive. They will spend time debating configuration instead of writing software.

Challenge

I would challenge anyone who thinks elm-format should be configurable to actually acknowledge this drawback, and make the less defensible (but more realistic) claim that the concrete loss of productivity across all elm-format users for all time is worth the ability to cater to one's personal preference regarding whitespace.

[srid]

making elm-format configurable makes teams using it indisputably less productive.

Making time to discuss styling conventions--be it globally (as we do here) or within the microcosm of a team, one time--does not necessarily mean being less productive (it is part and parcel of software development which is not all about writing code). Thus, your challenge has an implicit bias that discussing styling conventions leads to "concrete loss of productive across all elm-format users".

Even if--note 'if'--elm-format is to have a single formatting style, the question remains: how is this style choosen? Is it being chosen democratically or from within the walls of NoRedInk?

[rtfeldman]

Making time to discuss styling conventions--be it globally (as we do here) or within the microcosm of a team, one time--does not necessarily mean being less productive

Okay then, we'll have to agree to disagree on that premise. 🙂

(I do find it somewhat amusing that I'd explicitly planned to work on a new feature for elm-test tonight but find myself writing this sentence instead. Brains are weird.)

how is this style choosen?

As far as I know, Laszlo was the first person to write a public style guide for Elm, so that was the original starting point. It's never been democratic, because as @avh4 noted once on another thread, there's no way to get a representative sample. (Are people who knew there was a vote taking place more important users than those who didn't? What about people who aren't users today, but will be affected by its design in the future?)

So I'd say the design has evolved based on discussions of tradeoffs like the issue you linked to. (As an aside, I'm unclear on how a public GitHub issue resides "within the walls of NoRedInk," but that's neither here nor there.)

As an example of how design decisions are made, here is an example of @avh4 collecting and publishing data on 2 spaces versus 4 and another example where he talked about collecting input from community members on 2 vs 4.

To clarify the history here, 2-spaces was not chosen by popular vote. elm-format initially used 4-spaces, since that was the preferred style at the time. Some people had requested 2-space indentation, so I ran a survey to help me make an informed choice about whether or not to try 2-spaces.

Here is what the survey found:

• 85% of people have only tried one style
• 98% of people who have only tried one style prefer that style
• of the people who have tried both styles, 15% had no preference, and the rest were evenly split between 4-spaces and 2-spaces

Since most people had been using 4-space indentation, we decided to try 2-space indentation as an experiment to give it a fair chance. The feedback I've received from people who have now used both for extended periods of time has been in favor of 4-space indentation due to improved legibility.

This is how contentious decisions have been made on this project: collecting information and making decisions backed up by reasoning. For my money (which I guess is none, since this is open-source software that @avh4 makes in his spare time for free), this seems like the best way to go.

[srid]

@avh4 The feedback I've received [after trying 2-space indentation] from people who have now used both [2 and 4 space indentation] for extended periods of time has been in favor of 4-space indentation due to improved legibility.

Is the data for the feedback--upon which the current 2-space indentation decision is predicated upon--available in the open for public scrutiny?

I ask because I have hard time believing that more people opted for 4-space indentation despite the contrarian votes here on GitHub.

I know that NoRedInk--where the creator and some prominent members of the community are employed at--wants to make style discussions moot, but obviating needless style discussions in the name of purported productivity gains does not necessarily mean not being open about the data points that lead to the blessed style in a format. It leads me to wonder if making "style discussions moot" really means making them moot only outside of NoRedInk's walls.

[thaterikperson]

One more vote for the 2-space crowd. Not because 2 spaces are superior to 4, but because running elm-format on 10 thousand lines of Elm code just broke git blame for 80% of our Elm code. We'll get over this eventually, but switching does have a non-zero impact.

[wmakley]

I usually use Elm to implement small parts of Ruby web apps, and it kind of sucks to have two parts of my code base be on different tab lengths. Yes .editor-config is a great thing, but it's not always available and there is some readability argument to being able to have the entire project exactly the same.

Being forced to 4 spaces almost stopped me from using elm-format when I first read about it, although I did get over it eventually and the upsides do outweigh the downsides.

[tibastral]

2 spaces between functions and 4 spaces instead of 2 for tabs makes files bigger and larger, and I don't see it as more readable.

[wmakley]

I would add (not in response to the above comment) that, as a long-time user of elm-format, tabs is really the only thing I would definitely like to be able to customize, as I know there is some concern that this is a slippery slope towards a non-unified elm style. I would want to keep it at 4-spaces or whatever the global community default is when writing open-source packages, and some other indent to match the project I am using elm in for proprietary code (often a javascript or ruby pipeline).

I don't think one is more readable than the other, I have been using both for many years. I just use whatever the conventions of the project I am working on are.

[mezuzza]

This response only deals with @rtfeldman's argument above. Apologies for its long-windedness.
BLUF: I think there elm-format should allow some degree of configurability.

Configurability leads to some loss, but not a net loss in productivity

Previous argument:

1. There does not exist one single style that makes 100% of people happy.
2. These debates will never end. We have seen that not only here, in this thread and in others, but also in the JS ecosystem with the endless debates about semicolons and linter rules.

Completely agree on these points. I believe that most people would.

I would challenge anyone who thinks elm-format should be configurable to actually acknowledge this drawback, and make the less defensible (but more realistic) claim that the concrete loss of productivity across all elm-format users for all time is worth the ability to cater to one's personal preference regarding whitespace.

I'll grant that there is some loss of productivity when debating these things. However, I don't think that this leads to a net loss overall. Consider this:

1. Adding configuration would make adopting this a much easier pill to swallow for a lot of people (myself included). This means more people actually adopting this tool and saving more time overall.
2. Configuration allows elm-format to play nicer with other tools and languages which can result in productivity improvements over a team that works in multiple environments.

I feel that the first point alone leads to way more gains than any losses accrued by lunch debates on configuration.

There is some value produced from these debates

Remember also that while no single style satisfy everyone, no single style is perfect either. Each has some benefits over another. Example:

• 2-spaces makes indentation after divs not look weird in views.
• 4-spaces makes clearer demarcations of code blocks.

Some teams value some benefits over others and make choices about this. Allowing them to make that choice in the end leads to a value gain since they'd only do so if it was worth it. Honestly, this alone is probably a net loss in productivity.

However, I'd say most teams have better things to do than debate configuration and I would bet that most people don't actually care. Yes, there are quite a few debates on this repo, but it's filtered down to just the people who care enough about formatting and Elm to be reading issues on a ticket for elm-format. It's quite a biased sample. Most people wouldn't change these settings after they've been set.

Configurability does not lead to the loss of a blessed style

While some people will have small divergences from the standard, most will not. Not a perfect analogy, but take maven and gradle as examples of configurable tools. Obviously these tools allow for a large amount of flexibility in configuration, but maven and gradle are highly opinionated on how they should be configured. Those settings are largely untouched because changing them is only done in extreme cases.

Granted build tools require more flexibility than formatters, but opt-out behavior in general is well studied. Default values for configuration ensure that a blessed style exists.

Conclusion

Overall, you still retain a blessed style and improve productivity by introducing configuration. In my opinion, not doing so for the sake of improving global developer productivity is missing the forest for the trees.

[rtfeldman]

I'll grant that there is some loss of productivity when debating these things. However, I don't think that this leads to a net loss overall. Consider this:

1. Adding configuration would make adopting this a much easier pill to swallow for a lot of people (myself included). This means more people actually adopting this tool and saving more time overall.

Not gonna lie, I feel like "give me what I want or I'll refuse to use this tool and my productivity will suffer" is not a super compelling case. 😉

1. Configuration allows elm-format to play nicer with other tools and languages which can result in productivity improvements over a team that works in multiple environments.

I work on such a team. Our stack incorporates a variety of languages, and various team members use Atom, Vim, Emacs, Spacemacs, Sublime Text, and RubyMine. We all use elm-format and the only complaints I hear are about how the other languages we use don't have anything like elm-format.

Maybe there exist editors that don't play nicely with elm-format. At this point, given that the overwhelming majority of editors used by front-end programmers work great with it, I'm comfortable saying that in such a case the deficiency would be in the editor, not in elm-format's design.

I'd say most teams have better things to do than debate configuration

On this point we agree! 😸

[bgourlie]

In response to @mezuzza:

Some teams value some benefits over others and make choices about this.

Teams are made up of individuals, each with their own nuanced preference. Add configuration to elm-format, and this debate shifts from a single thread on a github repo to every team that uses Elm. You might say, "That's where the debate belongs!" and I would disagree—Not because elm-format happens to do things exactly to my liking, but because I've come to value consistency over things being exactly to my liking.

Anecdotally, I work in a Java shop and we use checkstyle to enforce code style. Google vends a canonical checkstyle configuration, so as a company we adopted that—Slightly modified, of course, because reasons. Every team that owns a code base uses the company checkstyle. Again, slightly modified, because nobody will ever agree on a single common style if given the choice. All the sudden, a tool intended to enforce consistency is being used to enforce inconsistency.

I propose this issue be closed. The README clearly states that the purpose of elm-format is to format code in a universally consistent way. Allowing any amount of configuration defies this tenet, and is much broader discussion than configurable tab length.

[crazymykl]

If the choice were between a rigid elm-format that 65% of Elmers used, and a configurable one that 80% used, with minor variations, which is providing more value?

I've heard of organizations refusing to even consider building in Go because "gofmt is infantilizing." I don't want Elm to suffer the same fate.

[bgourlie]

If the choice were between a rigid elm-format that 65% of Elmers used, and a configurable one that 80% used, with minor variations, which is providing more value?

I'd argue that 65% of all elm code being formatted consistently provides more value than a complete lack of consistency, which is what any amount of configuration will result in.

I've heard of organizations refusing to even consider building in Go because "gofmt is infantilizing."

go rubs a lot of people the wrong way, whether it's opinionated formatting or a lack of generics and exceptions. Whatever the stated reason for the distaste, it usually boils down to "I want the new thing to be like the old thing, because that's what I'm used to." Despite some companies anecdotally refusing to use go for whatever reason, the language is undoubtedly successful. To that end, I do want Elm to suffer the same fate.

[mezuzza]

@rtfeldman

Not gonna lie, I feel like "give me what I want or I'll refuse to use this tool and my productivity will suffer" is not a super compelling case. 😉

Not what I intended at all. I didn't say I wouldn't adopt elm-format, simply that it would make the decision and adoption easier. The point I was attempting to make was summarized quite well by @crazymykl. I also think that framing doesn't do justice to the rest of my argument as it only addresses one point.

In fact, I wouldn't even mind writing the configuration code myself. If all I really wanted was to increase my productivity, I'd just fork the repo like the others. I just think that the debate was not focusing at the right level and I wanted to clarify that.

@bgourlie
I think we've come to a fundamental impasse and I can respect that, but it becomes a philosophical point which has analogues in other fields (see state vs federal powers). In regards to "That's where the debate belongs!", yes I would say that. I don't think that level of consistency is important across teams. I just feel the whole situation is so minor that these small differences should just be allowed. And I would bet that even with all the minor variations, the code was still readable and still very similar to each other.

That said, I do agree that this is a debate about whether configuration should be allowed at all rather than being able to configure tab widths and should probably be moved to a different place.

Whatever the stated reason for the distaste, it usually boils down to "I want the new thing to be like the old thing, because that's what I'm used to."
You're right, but there's also something to be said about not making changes for the sake of doing so. I'm not saying that's what's happening here, I'm simply playing devil's advocate.

Ultimately, I think there's one big question that needs answered:
How should elm-format increase productivity? Should it focus on 65% of the population so that they lose 0 time and the other 35% loses 50, or should it focus on increasing the size of the population so that 80% of the population loses 5 time, while the other 20% lose 50? Obviously the numbers here are made up, but I feel like that frames the debate in a clearer way.

[rtfeldman]

Not what I intended at all. I didn't say I wouldn't adopt elm-format, simply that it would make the decision and adoption easier. The point I was attempting to make was summarized quite well by @crazymykl.

Gotcha. In that case I'll take a stand on this:

How should elm-format increase productivity? Should it focus on 65% of the population so that they lose 0 time and the other 35% loses 50, or should it focus on increasing the size of the population so that 80% of the population loses 5 time, while the other 20% lose 50?

The former.

With the understanding that:

• I used elm-format extensively back when it was 2-space as well as now that it's 4-space
• I have talked to several people who have tried both for extended periods of time
• I used Elm extensively before elm-format existed and I know what the productivity gap is once you've adjusted

...I am comfortable taking the following position:

Choosing not to use elm-format because of stylistic preferences is so close to indefensible that it rounds off to indefensible.

If the gap between the 65% and 80% in this hypothetical consists of 15% who are in that group because they've made an indefensible choice, then no, I don't think catering to them is reasonable.

[mezuzza]

If the gap between the 65% and 80% in this hypothetical consists of 15% who are in that group because they've made an indefensible choice, then no, I don't think catering to them is reasonable.

Fair enough, I can respect that stand.

Might I suggest closing out this ticket if that's the case? It sounds like the conclusion here is that this and configuration in general shouldn't be supported.

[crazymykl]

I am surprised that manual code formatting, the default for as long as I've been alive, is considered an "indefensible" choice.

[rtfeldman]

The same could have been said of punchcards before the obviously superior thing came out. 😉

[specious]

The beautiful thing about software is how configurable it is. Sure, giving it structure plays a critical role in making it maintainable, extensible and consistent, but flexibility is what ultimately makes software so attractive.

I vote for making spaces configurable with a default set to 4 per tab. Let it be a tool we want to use, not a tool we feel we are choosing for its benefits despite the trade-off it forces on us.

[felixakiragreen]

Here is an opinion from the peanut gallery.

I love elm-format. But because of lack of configurability, I'm having to disable it. I need my tabs to be 2 spaces.

[mybuddymichael]

For the sake of anecdote, I'll chime in. I much prefer two spaces to four. But I understand there are pros and cons to each option. And I'm tired, and the last thing I want to think about when I'm coding is how the code should be formatted. And since I'm tired, I don't want to be stressing over whether I'm using the correct configuration for any given tool. So I appreciate that elm-format just does its thing and that I don't need to fiddle with any configuration. It's simple and to the point. Its chosen tradeoffs may not be right for some people, but they're surely just right for many others.

[specious]

I have created a fork with configurable indentation via e.g., elm-format --tabsize 2

I want the community to have an option and to continue to enjoy this wonderful product. I'll open a pull request for review and I understand that you guys may decide not to merge it.

Cheers! 🍺

[specious]

Pull request open: #289

[tibastral]

You are awesome @specious !

[kuon]

I agree that the format should be unique, defined in a standard way (so I vote no for this issue).

But my vote also goes for 2 spaces. But if the elm community decides 4 is the standard, I'll follow. We HAVE to work out our difference and work together to make elm a great language with a strong community.

The two styles are already used in the doc (and even on the official style guide page), this is confusing. We can have all the argument in the world, I don't think there is an objective better choice between 2 and 4.

Pick one, please, and stick to it. No configuration, no changing every time the moon is full. If it's 4, then be it, I'll frown for a minute and change my .editorconfig. The frontend dev is a mess, we are fixing it, and we can't let an issue like this stay in the way.

For the record, the official style guide at the time of this rant:

[Namek]

@kuon Why not having flexible configuration for all projects but only one specific setting for projects shared as Elm libs? I see no point in voting here.

[kuon]

@Namek Because it will cause fragmentation, messy diff when people don't change editor configuration to "work on a lib" and all other kind of issue.

[felixakiragreen]

Ironically, if tabs were the standard instead of spaces, we could all define it exactly how we each wanted.

[kuon]

I don't hate tabs. I like the fact that makefiles are super strict about it. I don't remember why tabs were declared evil, but I remember it was very bad, like tabs were smashing kittens. But let's not start a tab vs space discussion or the sun will blow.

[rtfeldman]

Ironically, if tabs were the standard instead of spaces, we could all define it exactly how we each wanted.

There are nonobvious drawbacks to that approach. 🙂

[ghivert]

What about a .elm-format at the root of a project, redefining tab-width ? If file is present, then elm-format could apply the redefined tab-width, else it uses the standard config (4 spaces).

By doing that, we assure no configuration if newcomers are added to the project (elm-format automatically format according to the elm-format file) and it still minimizes the diff (inside of every project, elm-format is always consistent).

This solution could moreover include other customization if needed (newline after let, etc.)
(Linter Clang does something similar for instance.)

Would be glad to implement it asap if needed!

[wmakley]

Although I am feeling moved by @kuon 's impassioned defense of a standard tab width for all Elm code and plan to write all my Elm in 4-space indents, I feel that @ghivert 's proposal for a .elm-format file is the best compromise. I feel very strongly that all public packages should use the current elm-format defaults. The only place I would ever override the defaults is for proprietary code, and only then because the code was started without elm-format and I don't want to have a diff affecting every single line.

Based on my experience with linters and formatters for other languages, I have found that having a .linter-name file in version control to be a great way to get all developers in the project to follow the same style, much like .editorconfig and so forth.

[kuon]

I guess having an .elm-format would work, because it would ensure consistency in a project/repo and avoid most of the issues I am fearing.

I still think the official guides and documentation should all use the same format (we could have documentation generator enforce a style).

To summarize my point:

• Introduction to elm should be consistent, this means doc, example, tutorials... should all use the same style
• A single project should have it's consistency ensured, the .elm-format proposal would cover this

[rspi]

Defaulting to 4 spaces with the possibility to override it to two in a editorconfig or a some elm-format-conf feels like the right way. Then everyone not specifically changing it to two will use 4.
Any project using two will have the a config in the root of project and elm-format will read it.

There was never really discussion if we should use 2 or 4 spaces in my project.
We all wanted 2 and built our own binary. Others are probably doing the same.
Just saying..

[iwinux]

Coding styles should & must always be picked & enforced by project owner (creator), not anyone else. The look & feel of code has significat impact on the motivation of programming.

Community conventions are appreciated, but code formatters that are 100% un-configurable are totally not acceptable.

"One True Coding Style" just doesn't make sense - variance always exists, either in config, or in forks.

[rtfeldman]

I think exactly the opposite is true.

[kuon]

I think the code style is part of the language, elm for example uses /= instead of !=, for me saying that elm uses 4 spaces instead of 2 or tabs is the same thing. So I stay by my stance that I think it should be non configurable. And I'd go as far as to say that I'm fine with elm not compiling badly formatted code.

Most of the time when coding style is not properly defined, it's a time sink.

For example, Apple has a nice naming convention for cocoa: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html

I think this kind of convention are good and make code easier to read and understand.

But, as I also understand the need of some people to customize things. Having a per project configuration file is something I'm ready to accept but I am still against it.

[rundis]

I sincerely hope elm-format never ever becomes configurable. I may not agreed with everything (separate discussions/issues), but not having to care about it in my project because it's the standard is so liberating and frees up precious time to focus on solving actual problems. I have yet to hear any convincing argument (as in because it actually objectively or measurable has any benefit) for making it configurable.

Hope this thread closes as soon as possible, with the conclusion no configuration will be catered for. Any issues related to configuration automatically closed with a short statement stating why it will not ever happen. End of 😄

[rtfeldman]

@rundis I agree 100%!

[neerajdotname]

prettier did not have configuration in the beginning and I loved it. Now it has a few and just last week there was an issue in the company regarding usage of double quote vs single quote. Some did not want any configuration so initially, we went with prettier default which is to double quote all the strings.

However, folks who have been doing ReactJS for a while did not like it since ReactJS and some other famous JS tools use single quote.

I hope Elm grows. I hope elm-format grows in popularity. I hope elm-format is able to withstand the pressure of not adding more configuration.

[ghivert]

For me, the problem with not adding configuration is that it can split the community around the tooling, between the ones who use elm-format, and the others. I know people who do not use elm-format because of the tab length. Me included: I'm using elm-format at work, not for my personal projects.

It's too bad to split the community and lose people just because of tab length IMO. If elm aims to be mainstream, I think it's good to keep the community focused on one tool, one language, etc. When doing JS, you have hundreds of tools to do the same thing, just because people can't coordinate. What I love about elm is that you don't have such mess.

About configuration: a .elm-format file at root of the project redefining the settings for the project do not interfere with standard: if no file is detected, just use 4 spaces. And I think it's important to not tell to newcomers that elm-format is configurable: they can search later when they're accustomed with the tool, and want a little bit more customization.

[rtfeldman]

it can split the community around the tooling, between the ones who use elm-format, and the others

In the State of Elm 2017 survey, 91% of respondents who had tried elm-format reported that they preferred to use it. That's not a divided community, that's massive consensus.

And considering a major selling point of elm-format is that there is no configuration, the only way to please the few who want configuration is at the expense of the huge number that want the opposite.

I'm not really sure how that could be justified, to be honest.

[iwinux]

OK, that's your take. I can't make any objective argument to convince the 91%, and I'm not convinced by you either. Maybe it's time to stop arguing and do something else :)

Off topic: hope that code formatters of other languages (that I use) (yapf / rustfmt / Prettier in particular) stay configurable. It's so difficult to find a fun language with great ecosystem.

[srid]

@rtfeldman Interesting. Do you know the count of people who had tried elm-format (in that survey)?

[rtfeldman]

Not offhand, but it might be in here somewhere: https://youtu.be/NKl0dtSe8rs

On Sun, Jul 23, 2017, 10:32 AM Sridhar Ratnakumar [e-mail]
wrote:

@rtfeldman https://github.com/rtfeldman Interesting. Do you know the
count of people who had tried elm-format (in that survey)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/avh4/elm-format/issues/210#issuecomment-317257139,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABCxwP5SXNZUpT9sWKG-qS3G7IE43-r6ks5sQ1l5gaJpZM4I8KX9
.

[felixakiragreen]

Perspective from the _bad_ side

When I was learning Elm, I used elm-format and I loved it. It helped teach me the Elm standards and speeded up the learning process.

6 months later I stopped. I know knew how everyone else wrote their code, but I wanted mine different.

Why? Aesthetics.

1. Two spaces over four

Coming from traditional JavaScript, I grew up using tabs— but with the advent of React and Babel, 2 spaces became the standard. I’m used to it and it helps me understand indentation levels more easily than 4.

Compare:

view : Model -> Html Msg
view model =
    let
        page =
            case model.page of
                FriendListPage ->
                    Html.map FriendListMsg
                        (FriendList.view model.list model.viewState)

to:

view : Model -> Html Msg
view model =
  let
    page =
      case model.page of
        FriendListPage ->
          Html.map FriendListMsg
            (FriendList.view model.list model.viewState)

2. Excessive use of new lines

This one is fairly trivial but still bothers me significantly.

Compare:

decodeViewState : String -> ViewState
decodeViewState json =
    let
        jsonViewState =
            JD.decodeString JD.string json

        viewState =
            case jsonViewState of
                Ok string ->
                    case string of
                        "Expanded" ->
                            Expanded

                        "Collapsed" ->
                            Collapsed

                        _ ->
                            Expanded

                Err msg ->
                    Expanded
    in
        viewState

to:

decodeViewState : String -> ViewState
decodeViewState json =
  let
    jsonViewState =
      JD.decodeString JD.string json

    viewState =
      case jsonViewState of
        Ok string ->
          case string of
            "Expanded" -> Expanded
            "Collapsed" -> Collapsed
            _ -> Expanded

        Err msg ->
          Expanded
  in
    viewState

In a ~500 line Elm file, elm-format added ~50 lines, making it ~10% longer. That doesn’t help legibility for me, it makes it worse.

Conclusion

Both for teams and a community, elm-format is great because it enforces unity of style.

I agree 100% with @rtfeldman about the importance of disallowing configurability. One of my favorite qualities of Elm is how opinionated it is about everything. Because it has the right opinion. And to date, every issue I’ve had with Elm’s opinions, I’ve come round once I understood why.

However, I disagree that 4 spaces are better than 2. And I disagree that new lines are necessary after every = or ->.

So, I am a hypocrite: opinionated style and formatting are good. Until they’re not.

Out of curiosity, is there a path for changing the official style guide? Or does it come from Senpai Evan?

[Janiczek]

@dubert

Disclaimer: all comments below are written in all seriousness, and I'm mostly a "2 spaces" person, even though I don't mind elm-format rewriting them to 4 spaces.

[2 tab spaces over 4:] it helps me understand indentation levels more easily than 4

How does it do that? If your argument was "4 spaces makes lines too wide, overflowing 80 characters, etc", I could objectively see how you came to that conclusion, but how do you see the indentation better with 2 instead of 4? Out of curiousity, what about 1 space instead of 2?

view : Model -> Html Msg
view model =
  let
    page =
      case model.page of
        FriendListPage ->
          Html.map FriendListMsg
            (FriendList.view model.list model.viewState)

vs.

view : Model -> Html Msg
view model =
 let
  page =
   case model.page of
    FriendListPage ->
     Html.map FriendListMsg
      (FriendList.view model.list model.viewState)

I hope I don't sound aggresive. I just don't understand the claim.

[felixakiragreen]

@Janiczek Not at all :)

When I said, "understand indentation levels more easily", I meant that 2 is what I'm used to because of my JavaScript background. I don't know if there is any empirical evidence around the difference in legibility or understanding between 2 and 4. (Though I do find 2 nicer on the eyes)

However, I understand that Haskell uses 4, which is probably why Elm defaults to 4. But most [?] newcomers to Elm have a JS background, not Haskell.

[gdotdesign]

This is not about which is the best, there is no such thing. It comes down to preference, just as many other things (like ice cream, some prefers vanilla others chocolate).

[felixakiragreen]

I spent a couple hours reading through all the Elm discussions I could find on tabs vs spaces. It's clear that there is a huge division in the Elm community.

Most here are sick and tired of this debate. Some think it is resolved while others do not.

I fell in love with Elm for a lot of reasons, but the one that stands out the most is that it eliminates most of the tedious debates on which way to do something because it provides one _best_ solution.

However, here there isn't a best solution. But we desperately need resolution. Resolution that only Evan can provide. Otherwise it will only continue to divide us and keep recurring year after year.

The resolution can look like anything:
• Consistent indentation with 2 or 4 spaces are declared the standard
• Indentation formatting is declared optional

Why is this debate not resolved?

1. As of the time of this writing (24/8/17) the official Elm style guide does not specify a standard for indentation sizes. It only says:
   > "Do not be a maniac with indentation. Simplicity will be better in the long run."

It also shows a "Good" example using indentation with both 2 and 4 spaces:

homeDirectory : String
homeDirectory =
  "/root/files"


evaluate : Boolean -> Bool
evaluate boolean =
  case boolean of
    Literal bool ->
        bool

    Not b ->
        not (evaluate b)

    And b b_ ->
        evaluate b && evaluate b_

    Or b b_ ->
        evaluate b || evaluate b_

1. The personal use of indentation for the 10 members of the Elm github organization breaks down as follows: (if any are wrong please let me know and I'll update it)
   • agazso - no .elm contributions
   • avh4 - 4
   • evancz - 2
   • jcollard - mixed
   • jinjor - 2
   • johnpmayer - 2
   • laszlopandy - mixed
   • lukewestby - 4
   • maxsnew - 2
   • vilterp - mixed

That does not look like consensus. Additionally, the participators in the elm-format 2v4 discussion break down as follows:
• avh4 - 4
• bbugh - 2
• rtfeldman - 4
• fbonetti - 2
• oldfartdeveloper - 2
• mgold - consistency (4)
• pdamoc - consistency (4)
• groob - 2
• sporto - 2
• etaque - 2
• crazymykl - 2
• scottcorgan - 2
• klemola - 2

Why does it need to come from Evan?

He is the creator of Elm. This debate will only be resolved when he makes a stance. Then it can be put on the elm-lang website and filtered down to all the community packages.

The current state of indentation

@evancz uses 2 spaces:
• UrlParser
• SortableTable

elm-lang repos mostly use 2 spaces:
• Browser
• Url
While some are mixed:
• Core - 2 spaces
• Core - 4 spaces

Of the 30 official elm examples, 24 use 2 spaces:
• Checkboxes
These examples use 4 spaces:
• Binary Tree
• Boolean Expressions
These examples mix 2 and 4 spaces:
• Drag
• Quick Sort
• Merge Sort
• Either

In the elm-community there is a dominance of 4 spaces:
• elm-time, elm-datepicker, basics-extra, builtwithelm, material-icons, graph, html-test-runner, typed-svg, elm-test, webgl, list-extra, dict-extra, random-extra, elm-webpack-loader, elm-route, array-extra, json-extra, string-extra, result-extra, linear-algebra, parser-combinators, shrink, maybe-extra, elm-check, list-split, svg-extra
With a few using 2 spaces:
• elm-webpack-starter, elm-list-extra, intdict

Many of the most popular elm packages use 4 spaces:
• elm-css
• style-elements
• elm-mdl

Conclusion and plea!

If you read this and dismiss it because it's already been discussed or resolved, please hear me out. Even though I am biased and prefer 2 spaces over 4, it's more important for us to have a standard.

Even if the official policy is that indentation width doesn't matter, then libraries like elm-format can provide options. But right now we're trying choose between 2 and 4 when it's not up to us.

Help us, Evan Czaplicki. You're our only hope.

[jxbadam]

The awesome thing about unilateral decision making is that it leads to people taking action that they normally would not have taken.

For instance working in many development shops I have discovered that each and every one of them has had different coding styles.

What has happened in this particular instance is that the existing coding styles have conflicted with the fact that this formatter does not allow for configuration to cover these styles. Thus all of the shops I have worked in that decided to use Elm (just one) decided that the best course of action was to not argue with the maker of elm-format but rather to fork this repository and make our changes.

At the end of the day I guess as long as the primary author of a tool is happy..... 🥇

[ghivert]

Hi everyone! To contribute a little to the debate, but also to find out if I'm the only one using indent guides and feeling like there's a problem with the four spaces ?

Just behind the focus in the list, you can see that the indent guides are not correct, because of the fact that elm-format indent the nested list with two spaces due to the comma of the tuple... Same with the |>, which are only two spaces from the array...

I admit it's a detail, but I think it's a detail that matters when you're coding elm all day.

[rtfeldman]

@ghivert would you mind opening a separate issue for that? Seems stearate from this. 😄

[gdotdesign]

@rtfeldman I don't think that that is a separate issue. Do you really indent list elements with a tab (key) instead of a single space in lists or after a pipe? Is there someone who does that?

[kuon]

@ghivert I think the current behavior is correct. Consider the following:

[ firstElement
, [ thisList
  , isActually
  , theSecondElement
  ]
, thirdElement
]

Our three elements are aligned.

[Janiczek]

@ghivert Why not just write the contents of the new line (after , focus) with whatever wrong indentation your editor decides on, and then, y'know, run elm-format?

[ghivert]

@kuon I agree. But the indent you showed is clearly two spaces. The nested list is two spaces away from the first list.

@Janiczek I did it, and the indent guides are still not correct. I just took screenshots to better explain the problem.

You can see that the second screenshot is more consistent with the indent guides, as everything is aligned with commas and square brackets, where in the first case, the nested indent guides are badly aligned with the f of focus, but correctly indented with the array (the one with element and anotherElement). However, indent guides on the second array (the one with standard and focus) don't appear.

The problem seems easily fixed by setting tab length to two spaces. 😉
@rtfeldman Should I open a new issue for this ?

[kuon]

@ghivert you are missing my point. What I mean is that list content is NOT indented by the tab length. It is the natural indentation of the list. The elements of the list are not indented. They appear indented by two because the coma plus the space are two in width.

[rtfeldman]

Should I open a new issue for this ?

Yes please! ♥️

@gdotdesign this is an issue about configuration, not how the current indentation algorithm interacts with indent guides, so I'd say a separate issue definitely makes the most sense!

[gdotdesign]

@rtfeldman I think you are misunderstanding something, as I understand @ghivert comment was ironic and the question was _"Should I open a new issue for setting the tab length to two spaces?"_

Otherwise I don't really understand what the issue is exactly. It's changing the formatting of the lists from: [ + space + content to [ + 3 space + content? because that would make it so indent guides are shown.

[rtfeldman]

I took @ghivert's comment to be sincere, not ironic. 🙂

Regardless, it's a point that I don't think has been surfaced before, and which deserves discussion!

[jarcane]

FWIW, not all of us have the liberty of freely choosing our formatting style.

I work as an onsite consultant on a large codebase in Elm that was written by others long before me, and they settled on 2 spaces, and the result is that elm-format is useless to me because I am not at liberty to unilaterally change house style to suit its developers' preferences.

You can dismiss that as "unproductive" all you like, but the result is that without configurability, the rest of the benefits of elm-format are lost to me because of this.

[kuon]

@jarcane I fully understand. But the whole point of this thread is to avoid this kind of issue in the future. I guess we could make a --legacy-two-space-do-not-use-unless-you-know-what-you-are-doing kind of flag to help people maintain 2 spaces indented code base.

[avh4]

The discussion here has gone off-topic multiple times. As a lot of people are subscribed, I'm locking this issue until I have a chance to summarize the points that relate to the original issue. If you have a separate feature idea or suggestion, please create a separate issue.