== Why is this an issue?

Strings, just like any other ``++Object++``, should be compared using the ``++equals()++`` method.

Using ``++==++`` or ``++!=++`` compares references rather than values, and usually does not work.


=== Noncompliant code example

[source,text]
----
if (variable == "foo") { /* ... */ }
if (variable != "foo") { /* ... */ }
----


=== Compliant solution

[source,text]
----
if ("foo".equals(variable)) { /* ... */ }
if (!"foo".equals(variable)) { /* ... */ }
----


== Resources

* CWE - https://cwe.mitre.org/data/definitions/597[CWE-597 - Use of Wrong Operator in String Comparison]

ifdef::env-github,rspecator-view[]

'''
== Comments And Links
(visible only on this page)

=== on 11 Jul 2013, 16:28:39 Dinesh Bolkensteyn wrote:
I'm changing the severity to Critical as this is most likely a bug that will be caught at runtime.

=== on 11 Jul 2013, 17:18:18 Dinesh Bolkensteyn wrote:
Implemented by \https://jira.codehaus.org/browse/SONARJAVA-205

=== on 11 Jul 2013, 17:21:24 Dinesh Bolkensteyn wrote:
Fabrice, it looks like to me that this can also deprecate some Findbugs checks:


 ES_COMPARING_STRINGS_WITH_EQ

 ES_COMPARING_PARAMETER_STRING_WITH_EQ


I did not really get the difference between those 2 however

=== on 13 Apr 2015, 09:17:37 Dinesh Bolkensteyn wrote:
FYI, [~ann.campbell.2], this rule is not applicable to C# and VB.NET, where ``++==++`` works.

=== on 31 Oct 2018, 17:19:36 Tibor Blenessy wrote:
We are reopening this issue because it can be used as a bug activated by default in SonarWay, while RSPEC-1698 should remain a code smell.

=== on 31 Oct 2018, 17:36:38 Tibor Blenessy wrote:
In fact, it would be better to have a new rule, because we want to extend for boxed primitives (``++java.lang.Integer++``, etc...}}


endif::env-github,rspecator-view[]