https://kotlinlang.org logo
#ktlint
Title
# ktlint
p

Piotr Krzemiński

11/19/2023, 6:31 PM
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?
2
In particular, it adds another level of indentation and makes the whole thing longer by one line
1
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
p

Paul Dingemans

11/19/2023, 7:19 PM
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:
Copy code
val x =
   listOf("foo", "bar")
       .map { it.fooBar() }
and
Copy code
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.
j

Johan

11/19/2023, 9:38 PM
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.
👍 1
👍🏼 1
1
l

louiscad

11/20/2023, 7:18 AM
But this is currently not accepted, while it's common in Kotlin, readable IMHO, and perfectly in line with Kotlin official style guide:
Copy code
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?
p

Paul Dingemans

11/20/2023, 8:14 AM
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:
Copy code
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:
Copy code
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:
Copy code
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.
l

louiscad

11/20/2023, 8:36 AM
Probably a better example of some code that I believe looks fine, but that ktlint would currently reformat.
Copy code
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.
p

Paul Dingemans

11/20/2023, 4:21 PM
No, this will not be changed. If you do not want this behaviour you can simply disable the
multiline-expression
rule in the
.editorconfig
.
😟 1
👍🏼 1
2 Views