Hacker News Reader

Comment by ryandv | Hacker News Reader

Set theory...

There are self-identifying "senior software engineers" that cannot understand what even an XOR is, even after you draw out the entire truth table, all four rows.

View on HN

I am surprised at common it is for software engineers to not treat booleans properly. I can’t tell you how many times if seen ‘if(IsFoo(X) != false)’

It never used to bug me as a junior dev, but once a peer pointed this out it became impossible for me to ignore.

Clearly the correct spelling is

`if(X&IsFooMask != 0)`

People do that? This hurts my brain. if(IsFoo(X)) is clear and readable.

The most egregious one I saw, I was tracking down a bug and found code like this:

    bool x;

    ...

    if (x == true) {
        DoThing1();
    } else if (x == false) {
        DoThing2();
    }

And of course neither branch was hit, because this is C, and the uninitialized x was neither 0 nor 1, but some other random value.

Sometimes this kind of thing happens after a few revisions of code, where in earlier versions the structure of the code made more sense: maybe several conditions which were tested and then, due to changing requirements, they coalesced into something which now reads as nonsense.

When making a code change which touches a lot of places, it's not always obvious to "zoom out" and read the surrounding context to see if the structure of the code can be updated. The developer may be chewing through a grep list of a few dozen locations that need to be changed.

Maybe it was initially supposed to be a sort of "3-value boolean" (true/false/undefined) and not a standard bool. You can (rarely) meet this pattern in c++ if you use boost::tribool or in c# if you have a nullable bool. There is probably similar thing in other languages.

It was definitely just bad code.

I think of comparisons as a type conversion to a boolean. You wouldn't convert a boolean, but I like it to convert other types like an integer, even when the language rules would already specify the same I'm writing.

I've spent a lot of time not seeing how xor is just the 'not equals' operator for booleans.

Or, for a boolean type, that XOR is the same as the inequality operator.

Maybe it’s confusing because it’s misnamed?

This is like saying the non-negative integers under addition, lists under append, and strings under concatenation are all just misnamings of the semigroup operator.

https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-...

Is it? Two things are equal exactly when they aren’t exclusive.

XOR is for key splitting.

Reply on news.ycombinator.com