Enabled `UnnecessaryParentheses` rule and it reported this code ```offset.y.toInt() in item.offset....

# detekt

[dimsuz]

Enabled UnnecessaryParentheses rule and it reported this code

offset.y.toInt() in item.offset..(item.offset + item.size)

Sure, technically those can be removed, but wouldn't it look less readable? Do you think this might be an exception or config option?
If yes, I can create issue and occasionally a PR.

[gammax]

I think this is probably worth an exception in the rule config or a local suppress. 🤔
It’s essentially equivalent to:

i in 0..(1+2)
// vs
i in 0..1+2

[dimsuz]

yeah, maybe it should be a local suppress.

by the way, another one I found "controversial" is this code

(someClass.value.toInt() + otherClass.value) to (size + count)

vs

someClass.value.toInt() + otherClass.value to size + count

I find the latter less readable.

[ephemient]

if infix precedence confuses you, write it without

offset.y.toInt() to item.offset.rangeTo(item.offset + item.size)

(someClass.value.toInt() + otherClass.value).to(size + const)

[dimsuz]

oh, nice idea!

[ephemient]

that being said, while Kotlin's rules are straightforward (infix has precedence between arithmetic and logic, and always associates to the left), it does work differently enough from other languages that I can understand wanting a configurable warning about potential confusion, similar to Clippy's https://rust-lang.github.io/rust-clippy/stable/index.html#precedence. certainly it took me a while to get used to bitwise and and or having the same precedence, unlike & and | in every other language…

[dimsuz]

IIRC in haskell you can even override operator fixity (precedence) locally. And when creating new operators (which are functions of course), you can specify precedence.

[ephemient]

yes, and left/right/neither associativity can be specified as well. but I don't expect Kotlin to ever do that

[Brais Gabin]

The problem with this rule is that "readability" is a broad term so it's difficult to write a line. I agree with you, those parentheses help. I know that IntelliJ now have a rule that even tells you "It's true that you don't need parentheses here but we recommend to add them to improve readability". A port from that code could be a good compromise.