== Why is this an issue?

When working with ``++float++`` or ``++double++`` primitive types, it may be required to deal with ``++NaN++`` (Not a Number) values. When tested against itself, ``++NaN++`` will always answer ``++false++`` as long as the primitive wrapper type is not used. When the wrapper is used, it will always be ``++true++``. This property is illustrated in the code snipped below.


----
double d = getValue();
if (d == d) { // false for primitive 'double' when NaN, and true for any non-NaN values
  doSomething();
}

Double bigD = getValue();
if (bigD == bigD) { // always true for wrapper type 'Double' when NaN, AND with any other Double value
  doSomething(); 
}
----

In order to remove any ambiguity, this rule raises an issue every time an equality test is used with ``++double++``, ``++Double++``, ``++float++`` or ``++Float++``, when both sides of the test are the same variable. The ``++isNaN(...)++`` methods from ``++Double++`` and ``++Float++`` should be preferred.

=== Noncompliant code example

[source,java]
----
double x = getValue();
if (x == x) { // Noncompliant
  doSomething();
}
if (x == Double.NaN) { // Noncompliant
  doSomething();
}
----

=== Compliant solution

[source,java]
----
double x = getValue();
if (Double.isNaN(x)) { // compliant
  doSomething();
}
----

== Resources

* https://wiki.sei.cmu.edu/confluence/x/wzdGBQ[CERT, NUM07-J.] - Do not attempt comparisons with NaN

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

'''
== Implementation Specification
(visible only on this page)

=== Message

Replace this equality test with "Double/Float.isNaN(...)".


=== Highlighting

equality


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

=== on 31 Jan 2018, 16:53:17 Ann Campbell wrote:
\[~michael.gumowski] this rule duplicates RSPEC-2688. Make it a subtask?

=== on 31 Jan 2018, 16:57:46 Michael Gumowski wrote:
Arf, I missed that when I searched for ``++NaN++`` in RSPEC... Thanks for noticing it [~ann.campbell.2]. It's indeed a duplicate, but to me RSPEC-2688 is not that good as an explanation. What do you mean by making it a subtask? replacing the existing subtask?

=== on 31 Jan 2018, 17:23:05 Ann Campbell wrote:
\[~michael.gumowski] the main task talks about using a ``++NaN++``-testing function, which is what this rule also talks about. So yes, replacing the subtask makes sense to me, particularly if you don't like the suggested remediation in the existing subtask.

=== on 1 Feb 2018, 08:42:17 Michael Gumowski wrote:
\[~ann.campbell.2] Ok, so let's make it a subtask. Can you take charge of it? I'm not sure what to do with the previous one.

=== on 1 Feb 2018, 16:34:48 Ann Campbell wrote:
Done [~michael.gumowski]

=== on 2 Feb 2018, 08:08:30 Michael Gumowski wrote:
Thx!

include::../comments-and-links.adoc[]

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