-
Type:
Bug Detection
-
Status: Active
-
Resolution: Unresolved
-
Labels:
-
Message:
-
Highlighting:
- primary location: right operand
- secondary location: equivalent left operand
- message: "Identical sub-expression."
-
Default Severity:Major
-
Impact:Low
-
Likelihood:High
-
Default Quality Profiles:Sonar way
-
Targeted languages:Flex, PL/I, VB6
-
Covered Languages:ABAP, C#, C, C++, Cobol, Go, Java, JavaScript, Kotlin, Objective-C, PHP, PL/SQL, Python, RPG, Ruby, Scala, Swift, T-SQL, TypeScript, VB.Net
-
Irrelevant for Languages:HTML, XML
-
Remediation Function:Constant/Issue
-
Constant Cost:2min
-
Analysis Level:Syntactic Analysis
-
Analysis Scope:Main Sources, Test Sources
-
Common Rule:Yes
-
CERT:MSC12-C.
-
CPPCheck:comparisonFunctionIsAlwaysTrueOrFalse, duplicateExpression
-
ESLint:no-self-compare
-
ESLint-SonarJS:no-identical-expressions
-
FindBugs:SA_FIELD_SELF_COMPARISON, SA_LOCAL_SELF_COMPARISON, SA_FIELD_SELF_COMPUTATION, SA_LOCAL_SELF_COMPUTATION,RpC_REPEATED_CONDITIONAL_TEST
-
ReSharper:EqualExpressionComparison
-
TSLint-SonarTS:no-identical-expressions
Using the same value on either side of a binary operator is almost always a mistake. In the case of logical operators, it is either a copy/paste error and therefore a bug, or it is simply wasted code, and should be simplified. In the case of bitwise operators and most binary mathematical operators, having the same value on both sides of an operator yields predictable results, and should be simplified.
Exceptions
This rule ignores *, +, and =.
See
- CERT, MSC12-C. - Detect and remove code that has no effect or is never executed
- S1656 - Implements a check on =.
- contributes to
-
MMF-887 First pack of Typescript rules available as a TSLint extension
-
- Closed
-
- is implemented by
-
SONARFLEX-120 Rule: Identical expressions should not be used on both sides of a binary operator
-
- Open
-
-
SONARPLI-177 Rule: Identical expressions should not be used on both sides of a binary operator
-
- Open
-
-
SONARVBSIX-257 Rule: Identical expressions should not be used on both sides of a binary operator
-
- Open
-
-
CPP-612 Rule: Identical expressions should not be used on both sides of a binary operator
-
- Closed
-
-
SLVS-1022 Add identical expression on both side of binary operator rule
-
- Closed
-
-
SONARCOBOL-1190 Rule: Identical expressions should not be used on both sides of a binary operator
-
- Closed
-
-
SONARJS-350 Rule: Identical expressions should not be used on both sides of a binary operator (S1764)
-
- Closed
-
-
SONARPLSQL-609 Rule: Identical expressions should not be used on both sides of a binary operator
-
- Closed
-
-
SONARPY-141 Rule: Identical expressions should not be used on both sides of a binary operator
-
- Closed
-
-
SONARRPG-119 Rule: Identical expressions should not be used on both sides of a binary operator
-
- Closed
-
-
SONARSLANG-146 Enable in Ruby rule S1764 (IdenticalBinaryOperandCheck)
-
- Closed
-
-
SONARSLANG-215 [Scala] Enable Rule: S1764 Identical expressions should not be used on both sides of a binary operator
-
- Closed
-
-
SONARSLANG-284 [Apex] Enable Rule: S1764 Identical expressions should not be used on both sides of a binary operator
-
- Closed
-
-
SONARSLANG-415 [Go] Enable rules relying on Binary and Unary Expression, including two new rules (S1940, S1067)
-
- Closed
-
-
SONARSWIFT-59 Rule: Identical expressions should not be used on both sides of a binary operator
-
- Closed
-
-
SONARTSQL-12 Rule: Identical expressions should not be used on both sides of a binary operator
-
- Closed
-
-
CPP-707 Create Objective-C rules repository containing targeted rules
-
- Closed
-
-
CPP-2732 S1764: Add a message on secondary locations
-
- Closed
-
-
SONARJAVA-3584 S1764: Add a message on secondary locations
-
- Closed
-
-
SONARPY-796 S1764 raises an issue when "!=" or "==" is used to check if a value is "nan".
-
- Open
-
- is related to
-
RSPEC-4450 Java: "Double.isNaN" or "Float.isNaN" should be used
- Active
-
CPP-2951 S1764: Add support for <=>
-
- Open
-
-
SONARCOBOL-1411 Leverage commutative operators in IdenticalOperandsInBinaryExpressionCheck
-
- Open
-
-
CPP-2365 Improve S1764: non-const function should be an exception
-
- Open
-
-
CPP-2510 S3923: Improve code equivalence checking in case of macro expansion
-
- Open
-
-
SLVS-1060 S1764 and S2583 should not report on the same expression
-
- Closed
-
-
MMF-878 Java: New rules
-
- Closed
-
-
SONARPY-785 Fix FP on S1764 for expressions in try/except blocks
-
- Closed
-
-
RSPEC-2589 Boolean expressions should not be gratuitous
- Active
- links to
1.
|
Java | RSPEC-2079 |
|
Active | Unassigned | |
2.
|
C-Family | RSPEC-2080 |
|
Active | Unassigned | |
3.
|
COBOL | RSPEC-2584 |
|
Active | Unassigned | |
4.
|
JavaScript | RSPEC-2686 |
|
Active | Unassigned | |
5.
|
C# | RSPEC-2739 |
|
Active | Unassigned | |
6.
|
PHP | RSPEC-2839 |
|
Active | Unassigned | |
7.
|
RPG | RSPEC-2917 |
|
Active | Unassigned | |
8.
|
Swift | RSPEC-3088 |
|
Active | Unassigned | |
9.
|
VB.NET | RSPEC-3712 |
|
Active | Unassigned | |
10.
|
Python | RSPEC-3820 |
|
Active | Unassigned | |
11.
|
T-SQL | RSPEC-4090 |
|
Active | Unassigned | |
12.
|
PL/SQL | RSPEC-4229 |
|
Active | Unassigned | |
13.
|
Go | RSPEC-4514 |
|
Active | Unassigned | |
14.
|
Apex | RSPEC-4979 |
|
Active | Unassigned |