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".

So it just canonicalizes everything that is not a number into NaN.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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:

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.

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.

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.