16f6c0aecf
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
61 lines
2.0 KiB
Plaintext
61 lines
2.0 KiB
Plaintext
== Why is this an issue?
|
|
|
|
It is preferable to place string literals on the left-hand side of an ``++equals()++`` or ``++equalsIgnoreCase()++`` method call.
|
|
|
|
This prevents null pointer exceptions from being raised, as a string literal can never be null by definition.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,java]
|
|
----
|
|
String myString = null;
|
|
|
|
System.out.println("Equal? " + myString.equals("foo")); // Noncompliant; will raise a NPE
|
|
System.out.println("Equal? " + (myString != null && myString.equals("foo"))); // Noncompliant; null check could be removed
|
|
----
|
|
|
|
|
|
=== Compliant solution
|
|
|
|
[source,java]
|
|
----
|
|
System.out.println("Equal?" + "foo".equals(myString)); // properly deals with the null case
|
|
----
|
|
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
Move the "{}" string literal on the left side of this string comparison.
|
|
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== is related to: S1772
|
|
|
|
=== on 24 Jul 2013, 13:29:16 Dinesh Bolkensteyn wrote:
|
|
Implemented by \http://jira.codehaus.org/browse/SONARJAVA-224
|
|
|
|
=== on 18 Apr 2017, 10:53:00 Freddy Mallet wrote:
|
|
Removing the rule from Sonar Way, following user feedback about FPs when value on left side can not be null.
|
|
|
|
=== on 27 Oct 2022, 15:00:00 Michael Gumowski wrote:
|
|
After internal discussion, the rationale behind removing the rule from Sonar Way still holds.
|
|
|
|
* It is always a good practice to put the hardcoded string on the left side of the `equals()` call, since then it can never fail.
|
|
|
|
* However, if the value which is tested against the String can not be null (being protected by a null-check, or the value is known to be necessarily not null), then the issue which is raised can be considered by some users as FP.
|
|
|
|
* To make sure we only raise an issue when it makes sense and not generate noise, we would have to tie this rule with the Symbolic Execution (SE) engine. This is too much effort for such a simple code smell rules.
|
|
|
|
endif::env-github,rspecator-view[]
|