Ignore line length in string literals

[pkubowicz]

Let's have `.editorconfig'

[*.{kt,kts}]
max_line_length=40

and Kotlin file:

val string1 =
        "a very very very very very long string literal"

val string2 = "a very very very very very long string literal"

Ktlint 0.35.0 rejects both declarations:

LongLines.kt:2:1: Exceeded max line length (40) (cannot be auto-corrected) (max-line-length)
LongLines.kt:4:1: Exceeded max line length (40) (cannot be auto-corrected) (max-line-length)

I think at least line 2 should be accepted - it contains only whitespace and a string literal.

[Tapchicoma]

Why it should be accepted? :thinking:

You could split string literal using + sign. If you still want to have it long, add disable block around it.

[pkubowicz]

Since comments and raw strings are already not taken into account when checking line length.

Splitting string literal is risky - this string may be the expected value in a test and you may miss something if the string is contained in 2 lines:

assertThat(string).isEqualTo(
    "very very long" +
    "string but I missed space between lines"
)

Disabling blocks are very invasive as you need to open and close them, so you get 1:2 signal to noise ratio: 2 lines to satisfy ktlint in 1 line of code.

[Tapchicoma]

Another way - would be support disabling particular rules via @Suppress annotation.

[pkubowicz]

Supporting @Suppres would be nice in this case.

[ansman]

I agree, string in exceptions, deprecations etc should be allowed to be of any length as it's very inconvenient to split them.

[k1dbl4ck]

Would like to add that back ticked function names in tests should also be handled / ignored:

@Test
fun `Should return something when passing something and something and the other thing is in this or that state`() {...}

In this case it cannot be split.

[VishalNehra]

+1 Looking for a handly .editorconfig rule that I can include in disabled_rules

[florianmski]

Just adding my two cents for this issue that we hit in our current project. We found out as mentioned here https://github.com/pinterest/ktlint/issues/659#issuecomment-664319682 that this is not practical for tests names and sometimes you do really need that extra 20 chars to have a clear test name. I first set the max_line_length to off but it still seemed to auto format some of the code according to some hardcoded limit somewhere so I came up with the following which has been working great for the last few months or so, hope that helps:

in .editorconfig

[**/test/**.kt]
# setting this to `off` seems to make the IDE behave like there's a hard limit when auto-formatting
# which will wrap some assignments and methods calls, setting this up to a high value do the trick
max_line_length=1000

[mideuger]

I have the same problem, long string literals are common and splitting them is not a working solution and does not work with const values.

I've submitted 2 PR that aim to solve this problem in different ways :

• #1149 add an option to ignore single line raw strings, since multi line ones are already ignored by default
• #1150 add an option to subtract string length from the total line length à la ktlint_ignore_back_ticked_identifier

I would much rather prefer the second approach but I'm glad if one of them is a accepted/improved or the issue taken down in some way 🙂

[marciogranzotto]

Just adding my two cents for this issue that we hit in our current project. We found out as mentioned here #659 (comment) that this is not practical for tests names and sometimes you do really need that extra 20 chars to have a clear test name. I first set the max_line_length to off but it still seemed to auto format some of the code according to some hardcoded limit somewhere so I came up with the following which has been working great for the last few months or so, hope that helps:

in .editorconfig

[**/test/**.kt]
# setting this to `off` seems to make the IDE behave like there's a hard limit when auto-formatting
# which will wrap some assignments and methods calls, setting this up to a high value do the trick
max_line_length=1000

looks like you can define as max_line_length=-1 if you want to ignore that rule, at least on 0.31.0 which is the version that I'm using

[shawnthye-zalora]

@Tapchicoma what about Room database Query?

if we break like normal string, we lose the Query syntax support from Room 🤔

[paul-dingemans]

looks like you can define as max_line_length=-1 if you want to ignore that rule, at least on 0.31.0 which is the version that I'm using

Value -1 is not accepted, but you can set the value to off which will be translated by Ktlint to value -1.

[paul-dingemans]

String literals will not be ignored when checking whether the maximum length of the line is exceeded. Consider using a raw string literal instead, or the @Suppress("ktlint:standard:max-line-length").