5 ms·

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

by ryandv 1y ago

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.

BuyMyBitcoins 1y ago
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.
- catlifeonmars 1y ago
  Clearly the correct spelling is `if(X&IsFooMask != 0)` :)
- munchlax 1y ago
  People do that? This hurts my brain. if(IsFoo(X)) is clear and readable.
- furyofantares 1y ago
  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.
  - tomjakubowski 1y ago
    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.
  - Rexxar 1y ago
    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.
    - furyofantares 1y ago
      It was definitely just bad code.
- 1718627440 1y ago
  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.
layer8 1y ago
Or, for a boolean type, that XOR is the same as the inequality operator.
- avalys 1y ago
  Maybe it’s confusing because it’s misnamed?
  - ryandv 1y ago
    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-Monoid.html#v:-60--62- https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-...
  - layer8 1y ago
    Is it? Two things are equal exactly when they aren’t exclusive.
hyperman1 1y ago
I've spent a lot of time not seeing how xor is just the 'not equals' operator for booleans.
catlifeonmars 1y ago
XOR is for key splitting.

by ryandv 1y ago

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.

BuyMyBitcoins 1y ago

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.

catlifeonmars 1y ago
Clearly the correct spelling is `if(X&IsFooMask != 0)` :)
munchlax 1y ago
People do that? This hurts my brain. if(IsFoo(X)) is clear and readable.
furyofantares 1y ago
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.
- tomjakubowski 1y ago
  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.
- Rexxar 1y ago
  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.
  - furyofantares 1y ago
    It was definitely just bad code.
1718627440 1y ago
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.

layer8 1y ago

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

avalys 1y ago
Maybe it’s confusing because it’s misnamed?
- ryandv 1y ago
  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-Monoid.html#v:-60--62- https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-...
- layer8 1y ago
  Is it? Two things are equal exactly when they aren’t exclusive.

hyperman1 1y ago

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

catlifeonmars 1y ago

XOR is for key splitting.