Together with <@U3ZLHBTLG> we find this enforced s...

# ktlint

[Piotr Krzemiński]

Together with @louiscad we find this enforced style not really readable: https://github.com/typesafegithub/github-workflows-kt/pull/1109/commits/0b7dab1bf5a23d338dffc2e7bf6aa67f9c98fc5c. Is there any rationale behind this?

[Piotr Krzemiński]

In particular, it adds another level of indentation and makes the whole thing longer by one line

[Piotr Krzemiński]

So if one decides to just assign a result of some multiline function call to a val/var, they have to pay the price of reformatting

[Paul Dingemans]

Readability is subjective. It is definitely a change in style which you might need to get used to.

The rationale behind this is ‘consistency’. This rule enforces that multiline expressions are consistently formatted while without it, both examples below would be accepted:

val x =
   listOf("foo", "bar")
       .map { it.fooBar() }

and

val x = listOf("foo", "bar")
    .map { it.fooBar() }

If both styles are mixed in the same class / file / project it reduces readability and can lead to unneeded review remarks.

[Johan]

Why not set the rule to enforce the second case only then?
The only time I see any use of the first one is when the line gets too long.

This generates too many new "empty' lines, and I can't see how it makes the code more readable.

[louiscad]

But this is currently not accepted, while it's common in Kotlin, readable IMHO, and perfectly in line with Kotlin official style guide:

val x = listOf(
    "foo",
    "bar"
).map { it.fooBar() }

I find it particularly sad as almost always, the multiline expression is used to avoid lines that become too long, and yet, ktlint treats this style as if the lines were too long!

Is it "ktlint illegal" because it's too hard to make it take into account the line length?

[Paul Dingemans]

Why not set the rule to enforce the second case only then?

The only time I see any use of the first one is when the line gets too long.

This generates too many new “empty’ lines, and I can’t see how it makes the code more readable.

With short variable names, it makes sense to continue with the first part of the multiline expression on the same line. With longer variable names a disconnect between the first and second line of the multiline expression may occur:

val aLongerVariable = listOf("foo", "bar")
    .map { it.fooBar() }

Another reason is that this style is consistent with the wrapping of the expression body of a function where problem above becomes even more apparent when not wrapping the multiline expression:

fun Foooooooooooo.doSomething(bar: Bar) = try {
   // ...
} catch {
   ///
}

As described in the documentation the ktlint_official code style is the new default of ktlint. It goes beyond the Kotlin Coding Conventions and Androids Kotlin style guide. If you want to stick to old behavior, just still can use one of the other code styles.

``` val x = listOf(

"foo",

"bar"

).map { it.fooBar() }```

I find it particularly sad as almost always, the multiline expression is used to avoid lines that become too long, and yet, ktlint treats this style as if the lines were too long!

Above seems to be a bug. With a max_line_length of 29 it should have been formatted as:

val x =
    listOf("foo", "bar")
        .map { it.fooBar() }

But if the listOf(..) would contain more elements, or would exceed the max_line_length it will start wrapping the arguments at some moment.

[louiscad]

Probably a better example of some code that I believe looks fine, but that ktlint would currently reformat.

val x = listOf(
    "foo".butActuallyThisLineIsQuiteLong(),
    "bar".andThisLineIsAlsoPrettyLengthy()
).map { it.fooBar() }

Wouldn't you want ktlint to accept it going forward?

I understand the status quo, I'm asking if it can be changed for this case.

[Paul Dingemans]

No, this will not be changed. If you do not want this behaviour you can simply disable the multiline-expression rule in the .editorconfig.