https://kotlinlang.org logo
#detekt
Title
d

dimsuz

04/04/2022, 11:05 AM
Enabled
UnnecessaryParentheses
rule and it reported this code
Copy 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.
g

gammax

04/04/2022, 11:13 AM
I think this is probably worth an exception in the rule config or a local suppress. 🤔 It’s essentially equivalent to:
Copy code
i in 0..(1+2)
// vs
i in 0..1+2
d

dimsuz

04/04/2022, 11:17 AM
yeah, maybe it should be a local suppress. by the way, another one I found "controversial" is this code
Copy code
(someClass.value.toInt() + otherClass.value) to (size + count)

vs

someClass.value.toInt() + otherClass.value to size + count
I find the latter less readable.
e

ephemient

04/04/2022, 11:19 AM
if infix precedence confuses you, write it without
Copy code
offset.y.toInt() to item.offset.rangeTo(item.offset + item.size)

(someClass.value.toInt() + otherClass.value).to(size + const)
👍 1
d

dimsuz

04/04/2022, 11:21 AM
oh, nice idea!
e

ephemient

04/04/2022, 11:31 AM
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…
d

dimsuz

04/04/2022, 11:53 AM
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.
e

ephemient

04/04/2022, 12:01 PM
yes, and left/right/neither associativity can be specified as well. but I don't expect Kotlin to ever do that
b

Brais Gabin

04/04/2022, 12:43 PM
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.
👍 1