== Why is this an issue?

In a Zen-like manner, ``++NaN++`` isn't equal to anything, even itself. So comparisons (``++>, <, >=, <=++``) where one operand is ``++NaN++`` or evaluates to ``++NaN++`` always return ``++false++``. Specifically, ``++undefined++`` and objects that cannot be converted to numbers evaluate to ``++NaN++`` when used in numerical comparisons.


This rule raises an issue when there is at least one path through the code where one of the operands to a comparison is ``++NaN++``, ``++undefined++`` or an ``++Object++`` which cannot be converted to a number.


=== Noncompliant code example

[source,javascript]
----
var x;  // x is currently "undefined"
if (someCondition()) {
  x = 42;  
}

if (42 > x) {  // Noncompliant; "x" might still be "undefined"
  doSomething();
}

var obj = {prop: 42};
if (obj > 24) { // Noncompliant 
  doSomething();
}
----


=== Compliant solution

[source,javascript]
----
var x;
if (someCondition()) {
  x = 42;
} else {
  x = foo();
}

if (42 > x) {
  doSomething();
}

var obj = {prop: 42};
if (obj.prop > 24) {
  doSomething();
}
----


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

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

=== Message

Re-evaluate the data flow; this operand of a numeric comparison could be {"undefined"|an Object}.


=== Highlighting

Primary: Expression

Secondary: Path that puts comparison var in bad state


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

=== on 18 Oct 2016, 10:54:41 Pierre-Yves Nicolas wrote:
Similarly to RSPEC-3757, we may raise a false positive if the object has a ``++valueOf++`` method (which is the case for ``++Date++`` which we already exclude). We will refine that if the currently described behavior raises too many false positives.

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