Should scalafmt maxColumn example be same as Intellij default line limit of 120?

[samthebest]

Clarifications:

(1) Here when we say "Line limit" we mean the maximum number of characters in a single line of code before wrapping. In Intellij this comes under the setting "Hard wrap at"

(2) Also there is a "visual guide" which is a faint grey vertical line on each Intellij code tab indicating clearly to the user where they should break lines.

(3) scalafmt has an example configuration here: https://github.com/scalameta/scalafmt/blob/master/docs/configuration.md . This is currently maxColumn = 100.

Proposal:

To change the example configuration in the scalafmt docs from 100 to be the same as the default line limit in Intellij of 120.

Justification:

The existing example, when copy and pasted naively, can generate productivity hits to teams mainly as white space commits, and developers having to change their default settings in their IDE.

Intellij has existed since around 2001 and AFAIK the default has always been 120. Scalafmt AFAIK has existed around 2014, so Intellij predates scalafmt by 13 years. In total the majority of Scala developers, which number in the 10s of 1000s have for about 22 years been using a line limit of 120 characters.

It's hard to prove what line limit is used across all repositories in the Scala world, especially in private repositories. The following crude search indicates perhaps a ratio of 5x repos use 120 that also use scalafmt.

There are roughly 170 OS repositories that use 120 given by this approximate search: https://github.com/search?q=maxColumn+%3D+120&type=commits

Then about 33 for length 100 https://github.com/search?q=maxColumn+%3D+100&type=commits

Of the repos that do not use scalafmt we can reason that even greater than 5x repos will use 120, again, since that is the Intellij default.

Now I cannot prove that Intellij is the most widely used Scala IDE, but I have never heard someone claim otherwise.

The time it would take to change the example is of course the time it takes to change 1 character, and one maintainer to click merge. The time it would take for every scala developer to change their IDE settings is going to be in the order of 10,000x greater than that (not even accounting for the cost of unwanted white space commits arising from failed CI builds and such and such).

There is of course one final argument that is simply modern average monitor sizes have increased, as well as their resolution, hence 120 being deemed reasonable and 100 a little restrictive. But the crux of my argument is rather for the sake of consistency, since that is the very purpose of a scala formatting tool.

[tgodzik]

I added an explicit warning to not use the example configuration #3710 as this might cause some other problems. Also Intellij default formatter will format things differently, so it is important to either use scalafmt or only Intellij. I suggest using scalafmt as it's enforceable in CI.

I also suggest to raise it in scala contributors https://contributors.scala-lang.org/ as the topic of default configuration is something that needs to be raised at some point and maybe done via SiP

[kitbellew]

It's true that Intellij uses 120 as a starting value for all its languages but allows customization per language.

Also, while Java is its original language, the value of 120 does not correspond to the setting (100) hardcoded by the most frequently used formatter, google-java-format.

similarly, people who use the python language plugin would have to choose between pep8 (79), google style (80) or black default (88), none of which come even close to this global limit of 120.

therefore, I would argue that people who use automatic formatters would have to learn to override arbitrary values set within Intellij as it's not always possible to do it within the formatter.

the real issue is that Intellij's scala plugin allows modifying some values like hard right margin but hides (rather than deactivates) these settings if scalafmt is selected instead of built-in formatter.

a possible solution would be to modify the plugin to expose the maxColumn setting as the customized right margin when scalafmt is used. perhaps @unkarjedy could help with this, or point @samthebest to the right part of that plugin's code to contribute a fix.

finally, while I personally use Intellij, ignoring the existence of ever-growing user base of metals, especially within the context of vscode which is reportedly favored by 81% of developers (not specific to any language), and pretending that Intellij is the only game in town is hardly an objective approach to this issue.

[samthebest]

VSCode is 80 right?

Your comment here #3710 (comment) seems to be fair, accurate and informative and I'd be very happy with the suggested amendment in the conclusion of the comment.

[unkarjedy]

a possible solution would be to modify the plugin to expose the maxColumn setting as the customized right margin when scalafmt is used

I think it makes sense to add the integration between scalafmt maxColumn setting and IntelliJ "Visual guides" feature.
I would be grateful if someone reported a new ticket for that:
https://youtrack.jetbrains.com/newIssue?project=SCL

[kitbellew]

@unkarjedy added: https://youtrack.jetbrains.com/issue/SCL-21850, thank you!