SONARJAVA-6825: Implemented rule S9360 - Comparisons should not use Yoda conditions - #6022
SONARJAVA-6825: Implemented rule S9360 - Comparisons should not use Yoda conditions#6022romainbrenguier wants to merge 8 commits into
Conversation
…risons should be simplified This rule detects Yoda conditions where a constant literal appears on the left side of a comparison operator (==, !=, <, >). It reports an issue with the message 'Put the variable on the left side of this comparison.' The rule handles all literal types: integers, longs, floats, doubles, booleans, characters, strings, and null. It correctly skips parentheses to detect Yoda conditions in nested expressions like ((0) == count). Test coverage includes: - All literal types with == and != operators - Less than and greater than operators - Nested parentheses handling - Non-comparison contexts (assignments, arithmetic, method calls) - Edge cases: both literals, both variables, ternary operators
This comment has been minimized.
This comment has been minimized.
🤖 Generated with GitHub Actions
|
❌ Ruling needs updating. A fix PR has been created: #6023 Please review and merge it into your branch. |
- Fix compilation error: null cannot be compared with int primitive - Narrow rule description to Yoda conditions only (remove constant precomputation) - Fix compliant example conflicting with S1125 (flag==true) - Improve message for relational operators to mention reversing the operator - Add support for <= and >= operators Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Changes addressing review comments
|
✅ All code review findings resolved.
Ruling Diff SummaryDetected changes in 4 rule files: 0 issues removed, 109 issues added. S9360 (
|
🤖 Generated with GitHub Actions
|
❌ Ruling needs updating. A fix PR has been created: #6026 Please review and merge it into your branch. |
Add 6 new expected findings in eclipse-jetty for HttpStatus.java and AsyncJSON.java detected after adding LESS_THAN_OR_EQUAL_TO and GREATER_THAN_OR_EQUAL_TO operator support. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ithub.com:SonarSource/sonar-java into romain/yoda-condition-check
|
gitar unblock |
|
❌ Ruling needs updating. A fix PR has been created: #6028 Please review and merge it into your branch. |
|
❌ Ruling needs updating. A fix PR has been created: #6028 Please review and merge it into your branch. |
Code Review ✅ Approved 5 resolved / 5 findingsImplements rule S9360 to detect Yoda conditions with constant expressions and comparisons, addressing the previous compilation, rule description, compliant example, error message, and operator coverage findings. ✅ 5 resolved✅ Bug: Test sample does not compile: null == int breaks module build
✅ Bug: Rule description promises constant precomputation the check never raises
✅ Quality: Compliant example recommends code that rule S1125 flags
✅ Bug: Message for < and > tells users to make a semantics-changing swap
✅ Edge Case: <= and >= Yoda conditions are not detected
Implementation Status ✅ 1 of 1 objectives covered✅ SONARJAVA-6825 - 1 of 1 objectives coveredThis PR implements rule S9360 to detect and report Yoda conditions as part of the SONARJAVA-6825 objective. ✅ 1 covered here
OptionsAuto-apply is off → Gitar will not commit updates to this branch. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Gitar |
|
nathsou
left a comment
There was a problem hiding this comment.
Requesting changes for three blocking scope issues: verified duplicate findings with existing Java rules, divergence from the authoritative draft RSPEC, and incomplete handling of constants. The duplicate-report cases were reproduced with focused CheckVerifier tests on this exact head.
| Tree.Kind.FLOAT_LITERAL, | ||
| Tree.Kind.DOUBLE_LITERAL, | ||
| Tree.Kind.BOOLEAN_LITERAL, | ||
| Tree.Kind.CHAR_LITERAL, | ||
| Tree.Kind.STRING_LITERAL, |
There was a problem hiding this comment.
These literal kinds cause verified duplicate findings for equality operators. I ran focused CheckVerifier tests on this head with exactly each relevant rule pair enabled: true == flag produced S9360 + S1125, "hello" == text produced S9360 + S4973, and 0.0 == value produced S9360 + S1244. S1125 and S4973 are both in Sonar Way, so the first two duplicates occur in the default profile. Please make equality handling operator/type-aware: defer boolean equality to S1125, String equality to S4973, and floating-point equality to S1244, while retaining non-overlapping relational comparisons.
| private static boolean isLiteral(ExpressionTree tree) { | ||
| return tree.is( |
There was a problem hiding this comment.
This recognizes only bare literal AST nodes, not Java constant expressions. For example, -1 == result is a unary-minus expression and is silently missed; named constants such as Integer.MAX_VALUE == result and expressions such as 1 + 1 == result are missed as well. That conflicts with the rule's user-facing constant/Yoda-condition scope. Please either recognize constant expressions (at minimum unary +/- numeric literals) or explicitly narrow the specification and title to bare literals, with tests documenting the boundary.
|
superseeded by #6036 |




This PR implements rule S9360 'Constant expressions and comparisons should be simplified'.
The rule detects Yoda conditions where a constant literal appears on the left side of a comparison operator.
What the rule detects
0 == count→ should becount == 0null == obj→ should beobj == nulltrue == flag→ should beflag == true5 != x→ should bex != 50 < count→ should becount > 05 > x→ should bex < 5Supported operators
==(equality)!=(inequality)<(less than)>(greater than)Supported literal types
0,5,42)0L,5L)0.0,3.14)true,false)'a')"hello","")null)Edge cases handled
((0)) == countis detected0 == 0is compliant (nothing to swap)count == otherCountis compliantImplementation details
IssuableSubscriptionVisitorpatternEQUAL_TO,NOT_EQUAL_TO,LESS_THAN,GREATER_THANtree kindsExpressionUtils.skipParentheses()to handle nested parenthesesTest coverage
==and!=operators