[miguelrochefort]

Before reading your comment, I probably would have agreed with you that isOdd was overkill.

After reading your comment, I'm starting to think that isOdd is not only more readable but safer. I don't think I ever thought about n % 2 not handling negative numbers, and I'm not sure I would immediately recognize n & 1 as equivalent to isOdd. In languages without truthiness, n % 2 == 0 is longer than isOdd(n). Likewise, even with truthiness, n % 2 == 1 is longer than isEven(n).

I suspect that the real problem is the cost of adding dependencies, in terms of package size, performance, and security. All these problems could be solved using linking, inlining, and auditing.

[jraph]

But would you be sure that the implementation isOdd you are using is safe? To be sure you end up needing to try a few values, or to read the implementation, at which point you might as well write isOdd = n => n % 1.

That does not hold true for more complex stuff, but to test whether a number is odd, come on.

You'll test your code if it works anyway and if your odd test is wrong it will show.

But yes, you need to make sure on how '%' works in your programming language especially on negative numbers (and on non integers) because that can differ.

If you are testing whether a number is odd and that number can be negative, you'll probably think about it anyway.

That's a trap you should encounter once and then you are good.