No long lines

[MartinSStewart]

What the rule should do:
This rule is a generalization of https://package.elm-lang.org/packages/r-k-b/no-long-import-lines/latest/
It will report an error for any line that exceeds a specified character length. An exception is made for lines that can't be shortened without making changes beyond just inserting whitespace.

Example of things the rule would report:

a = [ "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf" ]

gets fixed to

a = 
    [ "asdf", 
     "asdf", 
     "asdf", 
     "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf" ]

which elm-format can then fix up.

Example of things the rule would not report:

a = "A very long string that exceeds the specified max line length"

The only place a line break can be introduced is here = " which don't make the line short enough to fit.

When (not) to enable this rule:

If it turns out to be too difficult to implement. There are some edge cases that might be tricky. For example:

a = case Nothing of 
    Just _ -> [ "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf" ]
    Nothing -> []

If we only apply a line break and a fixed amount of spacing to the long line, we'll end up with

a = case Nothing of 
    Just _ -> 
    [ "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf", "asdf" ]
    Nothing -> []

which won't compile since the expression needs to be indented past the start of the pattern match.

I am looking for:

• Is this rule useful?
• Are there other edge cases that make this rule difficult to implement?
• elm-syntax currently doesn't include line comments so a = "some text" ++ {- a comment -} "more text" will probably cause weird results. Does this seem like a big problem? Do people often place comments in lines of code?

[lydell]

If we only apply a line break and a fixed amount of spacing to the long line, we'll end up with [broken code] which won't compile since the expression needs to be indented past the start of the pattern match.

One idea is to insert "\n···················" instead of just a newline (· means space). The number of spaces could be a hardcoded 100 spaces or something, or the indentation level of the original line plus, say, 4 spaces. I think that should always be valid and fixable by elm-format.

But it might be better to let the user decide where to break the line. There might be multiple possible places that all result in a different result after running elm-format.

See also this issue in elm-format: avh4/elm-format#324

[MartinSStewart]

The problem I see with just inserting a lot of spaces is that it complicates figuring out if the line break was sufficient or if additional line breaks are needed to keep the line under the maximum character length.

[lydell]

Ah, gotcha. I guess it would be annoying if you had to run --fix 3 times before it got it short enough.

[sparksp]

I think it should be sufficient to report the long lines and not offer any fixes; this gives the developer the opportunity to identify a possible refactor, and lets them solve the complicated mess of where to insert the new line, how much to indent, and whether that's enough.

That said, you still need some way to identify whether a long line can be fixed.

If you're offering a fix, I see three problems that need to be solved:

1. where to put the new line,
2. how much to indent, and
3. is it enough? (repeat)

[jfmengels]

I am personally not fond of this behavior, as it makes certain things annoying (that bug me with Prettier for instance)

• Choosing an long expressive variable/function name over a shorter and more "mysterious" one can start making lines too long
• Indenting a piece of code (by adding a if) can suddenly change a lot of lines, which will make the git diff bigger.
• I start to fight the formatter or find (worse) ways around moving things to a new line, especially when I know I'm only one or a few characters past the limit. Sometimes that makes me want to rename a variable to something less meaningful 😞
• Concatenations of long strings become very ugly and harder to read. Sure, you have to scroll a lot when it's all on one line, but you have less gymnastics to do to figure out how the concatenation is done.

Most of these things I would do anyway myself when I feel like it is appropriate. But I see the value in enforcing it, to reduce the disparity in "code styles" in a team.
If elm-format would enforce it, then I would comply with it, but as I have noticed, it will potentially make my code a bit worse because I instinctively start to fight it.

Just like Richard in avh4/elm-format#324 (comment), I find that elm-format hits a pretty good spot of enforcing a consistent style while allowing for the choice for line-length.

Anyway, that was my point of view. Here are some edge-cases that I see if you feel like writing this rule anyway.

Module exposing line

I imagine that this rule will also report long import lines and the module X exposing (...) line.
For this latter one, I think you have to be careful not to run into an "infinite loop" when there are @docs in the module documentation.

module X exposing
  ( thing1, thing2, loooooooooooooooooooooooooooooooooooongThing
  , thing3
  )

{-|
@docs thing1, thing2, loooooooooooooooooooooooooooooooooooongThing
@docs thing3
-}
import ...

Here, regardless of how you will split the line containing the long thing, elm-format will revert it to how is was before, which will put you back to square one.
To avoid that, you'll need to split the @docs by adding a new @docs line. Then elm-format will move the exposing just right.

Performance

One thing to note is it's fine to have several round trips with elm-format when elm-review is run with --fix, but when you run --fix-all, elm-format will only be run after you receive the prompt. Meaning that every round trip adds an additional prompt to the user, which is unexpected and tedious for a user who wanted all errors to be fixed at once.

elm-syntax currently doesn't include line comments so a = "some text" ++ {- a comment -} "more text" will probably cause weird results. Does this seem like a big problem? Do people often place comments in lines of code?

I don't put many comments in my source code, but this does happen yes.
elm-format is sometimes a pain with regards to comments, making it already is plenty hard to put the comment exactly where you want. I think that this can be a problem, because comments are very often position-sensitive, and moving them can have unwanted impacts.

baseRegex =
  "(" ++ "\d\d\d\d-\d\d\d\d-\d\d\d\d-\d\d\d\d" -- Credit card number
       ++ "|\d\d\d\d-\d\d\d\d-\d\d\d\d"
       ++ ")"

could turn into

baseRegex =
  "("
       ++ "\d\d\d\d-\d\d\d\d-\d\d\d\d-\d\d\d\d"
       -- Credit card number
       ++ "|\d\d\d\d-\d\d\d\d-\d\d\d\d"
       ++ ")"

where the comment doesn't give the same meaning/explanation to the code
(This would already be modified by elm-format, but this is just to get the point across)

Spacing issue

As for the spacing issue that was raised where we wondered by how much to indent when splitting a line, I'm sure you can store the start column from the parent expression and indent it by a bit more than that amount, when the parent is on the same line.

[lydell]

Concatenations of long strings become very ugly and harder to read.

As far as I understood the proposal it would only complain about lines that can be made shorter by introducing line breaks (not ones where you’d have to “change the code”).

[jfmengels]

Concatenations of long strings become very ugly and harder to read.

As far as I understood the proposal it would only complain about lines that can be made shorter by introducing line breaks (not ones where you’d have to “change the code”).

I meant about concatenation of code like this:

Rule.error
  { message = "You have an error around module `" ++ moduleName ++ "` and function `" ++ functionName ++ "` on line " ++ String.fromInt line ++ "."
  , details = [ "Bla" ]
  }

which would turn into

Rule.error
    { message =
        "You have an error around module `"
            ++ moduleName
            ++ "` and function `"
            ++ functionName
            ++ "` on line "
            ++ String.fromInt line
            ++ "."
    , details = [ "Bla" ]
    }

[lydell]

Ah, I see. That’s good, in my opinion.