Add UnusedUnaryOperator rule

[t-kameyama]

Fixes #312

[codecov]

Codecov Report

Merging #3499 (471372e) into master (c5f65a9) will decrease coverage by 0.04%.
The diff coverage is 62.50%.

@@             Coverage Diff              @@
##             master    #3499      +/-   ##
============================================
- Coverage     77.63%   77.58%   -0.05%     
- Complexity     2814     2822       +8     
============================================
  Files           462      463       +1     
  Lines          8709     8732      +23     
  Branches       1688     1697       +9     
============================================
+ Hits           6761     6775      +14     
- Misses         1036     1037       +1     
- Partials        912      920       +8     

Impacted Files	Coverage Δ	Complexity Δ
...rturbosch/detekt/rules/bugs/UnusedUnaryOperator.kt	59.09% <59.09%> (ø)	8.00 <8.00> (?)
...turbosch/detekt/rules/bugs/PotentialBugProvider.kt	100.00% <100.00%> (ø)	3.00 <0.00> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c5f65a9...1737770. Read the comment docs.

[BraisGabin]

This case could have false negatives, but that's better than false postives for sure.

[cortinico]

Is there a reason why .not() (the !) unary operator is not considered in this rule?

[t-kameyama]

! cannot be used as a binary operator.

[picklebento]

I talked with my colleagus about this rule and found out some interesting discussions:

• Wrapping and +/- operators android/kotlin-guides#51
• Why new OperatorWrapping rule? pinterest/ktlint#163

With some manual testing

val d = 1
    + 1

would fail because of unary-op-spacing + 1 should be +1.

But even we change it to +1

val d = 1
    +1

still failed because of indent Unexpected indentation (8) (should be 4)

I believe this new rule is already covered by the combination of unary-op-spacing and indent, which does not require type resolution. Therefore my proposal would be not to add duplicate rules.

[t-kameyama]

ktlint reports nothing in the following case:

fun test() {
    val x = 1 + 2
    +3
}

[picklebento]

ktlint reports nothing in the following case:

fun test() {
    val x = 1 + 2
    +3
}

In this scenario, +3 is clearly a separate line instead of the continuation of the previous line.

[t-kameyama]

I think this problem is easier to understand with one detekt rule than with a combination of two ktlint rules, but if you don't need this rule, close this PR.

[picklebento]

@cortinico @BraisGabin What do you guys think? If both of you support this rule, I am fine with merging this in.

[cortinico]

What do you guys think? If both of you support this rule, I am fine with merging this in.

I don't have a strong opinion honestly. I would lean towards merging this. Mostly because is disabled by default and because explicit is better than implicit, we offer a rule that covers this exact scenario rather than "suggesting" a combination of two.

[BraisGabin]

I think that this is a code smell problem, not a formatting problem. So I vote to merge it.

It would be nice to have "experimental rules". Rules that we are not sure if we want to keep or not because they can have far too much false positive or they could be too subjective... But I don't think that this rule should wait for us to implement something like that.

[picklebento]

Thank you for the great test coverage. I played around with the code a little bit and found that those test cases were quite exhaustive for false positives.