6 ms·
I’ve seen the same thing, it might be generational. Someone arguing that we need an isNotEqual(a, b) helper in addition to isEqual(a, b), because that’s suppose
by codeflo 2y ago
I’ve seen the same thing, it might be generational. Someone arguing that we need an isNotEqual(a, b) helper in addition to isEqual(a, b), because that’s supposedly “cleaner” and more readable than !isEqual(a, b). They were very vehement about it, but I don’t get that at any level. It’s more lines of code to write and maintain, more unit tests, more characters to type at the usage site and to me, reads exactly the same way.
- utensil4778 2y agoFor me, reading isNotEqual() introduces an extra mental variable. I have to spend extra effort to keep track of the bar over the statement that doesn't exist in the text. But that said, I see no reason that someone couldn't learn to parse notX as fluently as I parse !X. I suppose it's one of those fashions that change with the times. Probably a big reason that I stick to good old C a lot of the time.
- lambdaxyzw 2y agoOne problem is that when refactoring it's easy to make a monster like "if (!notX()) ..."
- 8372049 2y agoMy personal opinion is that 'not' (Python-style) should be the operator instead, simply because it's easier to miss a ! than a 'not'. With that said, I'm with you in the 'not isEqual(a, b)' camp. The exception, imo, is functions that take boolean arguments. Languages should make it easy to show what they mean, and devs should take care to explain them. sort(reverse=true, numeric=false) is much easier to read than sort(true, false). (Silly example, it's meant to illustrate the general point, not to say anything about the signature of a sort() function.)