Add CascadingCallWrapping style rule #4979

dzirbel · 2022-06-21T00:29:11Z

Add a new rule CascadingCallWrapping which requires that if a chained call is placed on a newline then all subsequent calls must be as well, improving readability of long chains.

The rule name was chosen to be less ambiguous with ktlint's ChainWrapping, but could possibly be improved. I've taken the liberty of enabling it in detekt's own configuration file and fix a handful of existing issues.

3flex · 2022-06-21T03:27:03Z

Thank you for this rule! I've been wanting this for a while but didn't get around to writing it.

I'll review in more detail later. One thought: would you consider adding a configuration where there is a maximum number of chained calls on a single line? E.g. allow only 2 on a single line as a maximum, then require wrapping?

dzirbel · 2022-06-21T07:14:54Z

One thought: would you consider adding a configuration where there is a maximum number of chained calls on a single line? E.g. allow only 2 on a single line as a maximum, then require wrapping?

I'd had the same thought but didn't add it initially since I thought it might add too much complication. Happy to add it here, but it raises the question of how it would be configured, e.g. 0 to allow any number of calls on the first line? An alternative is to enforce that as a separate rule, which could then be more intuitively configured. Thoughts?

Another piece I was thinking about is whether to require wrapping for any calls that are split across multiple lines; there's a test case for the current behavior but personally I'd tend to wrap each of those calls. I was also leaning toward enforcing that in a different rule to avoid making this one too heavy but it also has a natural connection.

3flex

This is great! I'm a big fan of this rule, thanks again for implementing.

...s-style/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/style/CascadingCallWrappingSpec.kt

3flex · 2022-06-21T12:11:56Z

Good point on the configuration concerns, I hadn't thought that far ahead. A separate rule probably makes sense - if it just checks if there are x chained calls and that's over the y threshold then it would report a violation and tell you to split over multiple lines. Then this rule would still be there to make sure that if the chain calls are split, then all of them are on a unique line. That makes sense.

whether to require wrapping for any calls that are split across multiple lines; there's a test case for the current behavior but personally I'd tend to wrap each of those calls

I think that behaviour is fine and reflects this semi-official guidance: Kotlin/kotlin-style-guide#9 (comment)

dzirbel · 2022-06-21T19:49:08Z

I think that behaviour is fine and reflects this semi-official guidance: Kotlin/kotlin-style-guide#9 (comment)

Thanks for the link - didn't realize there was a project for contribution to the style guide! I think using breaks probably depends on the number of chained calls but IMO it's still subjective at best, so I'm also leaning toward not adding it as a rule.

marschwar · 2022-06-21T21:30:16Z

...s-style/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/style/CascadingCallWrappingSpec.kt

+        assertThat(findings).hasSize(1)
+
+        val finding = findings.first()
+        assertEquals(TextLocation(start = 8, end = 30), finding.charPosition)
+        assertEquals(
+            "Chained call `plus(0)` should be wrapped to a new line since preceding calls were.",
+            finding.message,
+        )


Please do not use junit assertions

Suggested change

assertThat(findings).hasSize(1)

val finding = findings.first()

assertEquals(TextLocation(start = 8, end = 30), finding.charPosition)

assertEquals(

"Chained call `plus(0)` should be wrapped to a new line since preceding calls were.",

finding.message,

)

assertThat(findings)

.hasSize(1)

.hasTextLocations(8 to 30)

assertThat(findings.first())

.hasMessage("Chained call `plus(0)` should be wrapped to a new line since preceding calls were.")

Good call, I'll do you one better by using first() on the assertion

marschwar · 2022-06-21T21:36:14Z

...rules-style/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/style/CascadingCallWrapping.kt

+        }
+    }
+
+    @Suppress("CanBeNonNullable") // false positive: callExpression cannot be made non-nullable


I tend to agree with detekt here ;) In which circumstances would the callExpression actually be null?

If the callExpresssion actually is null, this will mess up the error message. IMO it would be better to verify on the call side that the parameter is actually non null.

I think this is a clear false positive; callExpression can't just be made non-nullable - it can be null when either KtQualifiedExpression.selectorExpression or KtBinaryExpression.right are null (which I've never seen in practice, but they are both declared nullable), and the function isn't a no-op when it is null.

But your point still stands that the error message will be less useful if it is null. I don't think the solution is to verify it on the call side since I think we'll still want to generate a warning even if the right expression is missing. I'll improve the error message for the null case to just omit it.

marschwar · 2022-06-21T21:57:21Z

...rules-style/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/style/CascadingCallWrapping.kt

+    private fun String.containsInRange(needle: Char, startIndex: Int, endIndex: Int): Boolean {
+        for (i in startIndex until endIndex) {
+            if (this[i] == needle) {
+                return true
+            }
+        }
+
+        return false
+    }


How about?

private fun String.containsInRange(needle: Char, range: IntRange): Boolean { return range.any { this[it] == needle } }

or

private fun String.containsInRange(needle: Char, startIndex: Int, endIndex: Int): Boolean { return (startIndex until endIndex).any { this[it] == needle } }

Feel free to ignore this comment ;)

Good idea; this was probably a premature optimization to start with but using your second idea at the call site (since it's only used once) makes it cleaner.

Add a new rule CascadingCallWrapping which requires that if a chained call is placed on a newline then all subsequent calls must be as well, improving readability of long chains.

cortinico

Nice rule :) Thanks for sending this over

BraisGabin

👏👏👏 Great rule 👏👏👏

Add a new rule MaxChainedCallsOnSameLine to limit the number of chained calls on placed on a single line. This works well alongside CascadingCallWrapping in #4979 to make long call chains more readable by wrapping them on new lines.

DHosseiny · 2022-11-30T07:44:41Z

This is a useful rule, thanks for writing this. But there is a case this is annoying. Example:

tabsToDeepLinks
    .toList()
    .firstOrNull { pair ->
        pair.second == toUri
    }?.let { pair ->
        switchTab(tabIndex = pair.first)
        return true
    }

The let function is after a lambda so in this case, I think it is acceptable to not be in a new line. Generally speaking, let the chained call be in the same line with the previous function's lambda end if the previous function's lambda is not one lined. At least add a Configuration options for this case.

DHosseiny · 2022-11-30T07:48:43Z

Let me know if I should open an issue for this.

BraisGabin · 2022-11-30T08:03:53Z

I don't agree with that but please, open an issue so other people can give their opinions

DHosseiny · 2022-11-30T08:17:48Z

#5587

github-actions bot added the rules label Jun 21, 2022

vercel bot deployed to Preview June 21, 2022 00:34 View deployment

github-actions bot added api gradle-plugin labels Jun 21, 2022

vercel bot deployed to Preview June 21, 2022 00:51 View deployment

3flex approved these changes Jun 21, 2022

View reviewed changes

...s-style/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/style/CascadingCallWrappingSpec.kt Outdated Show resolved Hide resolved

...s-style/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/style/CascadingCallWrappingSpec.kt Outdated Show resolved Hide resolved

vercel bot deployed to Preview June 21, 2022 19:49 View deployment

dzirbel mentioned this pull request Jun 21, 2022

Add MaxChainedCallsOnSameLine style rule #4985

Merged

marschwar reviewed Jun 21, 2022

View reviewed changes

Add CascadingCallWrapping style rule

323e481

Add a new rule CascadingCallWrapping which requires that if a chained call is placed on a newline then all subsequent calls must be as well, improving readability of long chains.

vercel bot deployed to Preview June 21, 2022 22:39 View deployment

cortinico added this to the 1.21.0 milestone Jun 22, 2022

cortinico added the notable changes Marker for notable changes in the changelog label Jun 22, 2022

cortinico approved these changes Jun 22, 2022

View reviewed changes

BraisGabin approved these changes Jun 22, 2022

View reviewed changes

BraisGabin merged commit 89f6ec1 into detekt:main Jun 22, 2022

BraisGabin mentioned this pull request Jun 22, 2022

Don't allow the usage of junit assertions #4990

Closed

dzirbel deleted the allChainedCallsOnNewLine branch June 22, 2022 20:12

Uh oh!

Add CascadingCallWrapping style rule #4979

Add CascadingCallWrapping style rule #4979

Uh oh!

Conversation

dzirbel commented Jun 21, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

3flex commented Jun 21, 2022

Uh oh!

dzirbel commented Jun 21, 2022

Uh oh!

3flex left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

3flex commented Jun 21, 2022

Uh oh!

dzirbel commented Jun 21, 2022

Uh oh!

marschwar Jun 21, 2022

Choose a reason for hiding this comment

Uh oh!

dzirbel Jun 21, 2022

Choose a reason for hiding this comment

Uh oh!

marschwar Jun 21, 2022

Choose a reason for hiding this comment

Uh oh!

dzirbel Jun 21, 2022

Choose a reason for hiding this comment

Uh oh!

marschwar Jun 21, 2022

Choose a reason for hiding this comment

Uh oh!

dzirbel Jun 21, 2022

Choose a reason for hiding this comment

Uh oh!

cortinico left a comment

Choose a reason for hiding this comment

Uh oh!

BraisGabin left a comment

Choose a reason for hiding this comment

Uh oh!

DHosseiny commented Nov 30, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DHosseiny commented Nov 30, 2022

Uh oh!

BraisGabin commented Nov 30, 2022

Uh oh!

DHosseiny commented Nov 30, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

dzirbel commented Jun 21, 2022 •

edited

Loading

DHosseiny commented Nov 30, 2022 •

edited

Loading