Tooling based formatter for consistent style and better readability about mlscript HOT 3 CLOSED

I added some configuration to this.

plugins.sbt

addSbtPlugin("org.scalameta" % "sbt-scalafmt" % "2.4.3")

I added more configuration from sbt-scalafmt-defaults which has a collection of default scala settings.

After this running sbt scalafmtAll formats all scala source files in the project. There are task keys that can be used to add formatting checks to CI as well.

I'm linking a PR for review to check that the settings and reformatting rules are comfortable.

from mlscript.

Thanks for the suggestion, but I'm a bit torn on the subject of automated formatting.

On one hand, I agree that the formatting in the current code base is messy in some places, and can be improved. We try to keep under 100 columns, but sometimes don't respect that.

On the other hand, I often deeply dislike the output produced by scalafmt. Whenever something overflows, it suddenly choses to put everything on different lines, even single parens and braces, creating a huge amount of wasted whitespace and essentially noise.

We've actually been using scalafmt in another project, and I find it quite annoying. It creates needlessly big diffs for small changes when it decides to refactor the whole expression's layout, for example.

I found the dense code difficult to navigate and understand

I'm not surprised you found the code hard to follow, but I'd be surprised if that was mainly because of the formatting. The code base is at times quite complex. Introducing excessive whitespace in the middle of complex and dense logic does not make the logic simpler to understand, unfortunately. Quite the contrary I would say – the more information-dense the code is, the more you can grasp at a glance without having to go back and forth across wastelands of auto-formatting gore generated by scalafmt 😛

I think the code logic should be better documented and simplified, for example by using more intermediate functions and more named local values. This is likely yo have a much bigger impact than formatting.

So I'd much rather you suggest clarifying changes and manual formatting improvements whenever you come across such things, than to adopt automated formatting for the project wholesale, at least for now.

from mlscript.

As we discussed in the sample PR, commonly used formatting rules makes many whitespace changes and creates larger diffs. This is not desirable.

However there is some value to having consistent (if not very strict) styling. It does make it a little easier to write and understand. There could be a bare bones formatter setting that could be created from these possible configurations.

Some points I can think of -

• white space formatting (2 spaces, remove trailing white space)
• new line before method, class, object declarations to make it less like a wall of text
• shorter lines while staying withing a nesting depth limit

from mlscript.