d

    dimsuz

    5 months ago
    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

    gammax

    5 months ago
    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
    d

    dimsuz

    5 months ago
    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.
    e

    ephemient

    5 months ago
    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)
    d

    dimsuz

    5 months ago
    oh, nice idea!
    e

    ephemient

    5 months ago
    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

    5 months ago
    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

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

    Brais Gabin

    5 months ago
    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.