I don't think what the author says is the intent of the code. isNaN() returns true not just for NaN but for anything that is "not a number"[1]. For example, it returns true for things like "hello".<p>So it just canonicalizes everything that is not a number into NaN.<p>[1] <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/isNaN" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...</a>
I agree with the author that this is a reasonable way to indicate their intent. But I've seen so many accidentally ineffectual code snippets that if I saw this code I'd be inclined to delete it unless there was also a comment expressing its purpose.
I don't know if that was the real intent of this code, considering all the weird nuance around NaN in Javascript - however I agree with the point the author makes, and will take it one step further:<p>We should be building these semantics directly into our languages, not relying on programmers to strictly follow a "best practice". In this case, it would be making values non-nullable and baking in Result/Option/etc style types that force programmers into handling the null (or NaN) case.
This communicates an important idea, Well-written code is not only correct and efficient, but it is also readable, maintainable, and understandable to other programmers.<p>This culture should be encouraged more to make other developer's life easier, The thing I do nowadays is that I would often switch perspectives now and then, When switching perspectives, if i become confused, i would work on making the code more meaningful.<p>Even if we are doing a solo project, if we come back to the code after a long while, the code should be greeting us with wide open hands rather than looking like an unexplored jungle.