I get what you mean by switcher variable now. In case of toggling there is certainly a use for ^=, although I wouldn’t use it. To bad the != operator does something completely different …

I have to admit that I was a big friend of smart operator trickery in the past. Working in a team changed my mind. It’s better to make code as easy to grasp as possible. People usually have a better time understanding the underlying concepts and algorithms, if there is less need to explain what the code is actually doing.

In addition, today’s minifiers do a great job. I even abstain from certain JS “idioms”, because the minifier will replace longer constructs with them.

Example (with closure compiler):

if (!n) n = defaultValue; → n||(n=defaultValue);

Sure, every halfwhat experienced JS programmer could or should have seen the short form. But I think the longer version is easier to get. And as of today there is no longer a file size penalty. I just try to keep the cognitive demands of my code as low as I can.

I think the programming language should dictate my “halfwhat experienced programmer” statement more. However, binary operators are/should be pretty much “above” the layer of a language, hence, if you know how they work you can apply that knowledge in any language.

The “switcher” actually IS a nice geeky thing to have a state variable beyond standard boolean values:

var isReady = 0;
 
// somewhere else
if( isReady ) { }
 
// somewhere else, set isReady state to 1
isReady ^= 1;
 
// somewhere else, set isReady state to 0
isReady ^= 1;

Of course those things should always come along with own little specs (for a team), anyways this specific example shows demonstrates how to accomplish a state-shift without booleans. Is that more readable? No, I don’t think so, but its still very understandable imo. I could also argue that someone just sets a boolean variable to “foobar hey 42 I screwed your code”, so the human factor is always the biggest opportunity for failure.

Constructs like `~~(num)` are bad, because they hide the intention of the code and might not even work as desired.

If the number to round is already referenced by a variable, it could be floored using n - n % 1. This might not be as readable as floor(n), but it allows to get the intention.

I love to use bitwise operators aswell and I don’t think they decrease readabilty (at least not to any halfwhat experienced programmer I guess).

I think the algorithm should set the level, not the syntax used. Within the topic of parsing unicode and identifying surrogate pairs code like (codePoint & 0xFC00) == 0xDC00 is totally acceptable, because the topic requires knowledge about unicode. And programmers with that knowledge are likely to have knowledge of encodings, i.e. binary representations.

I’m not sure whether I got the term “switcher variable” correctly, but if it is only a condition, using ^= 1 is just a geeky try to appear smart with much opportunity for failure.

false ^ 1 // 1
true ^ 1 // 0
2 ^ 1 // 3 (intended truthyness?)
{} ^ 1 // 1 (whoospie or intended?)

The speed reason for external libraries: Why not benchmark it with

@Sujay, I would prefer to use the more verbose/slower Math.floor instead of adding a comment for what should be such a rudimentary operation. IMO Having a comment there would just make the situation even more seemingly complex for maintainers.

And `-~` looks cool. Not considered that before.

Some of my open-source JavaScript projects are drop-in libraries, and in those cases I make use of bitwise operators for non-bitwise use cases as I see fit. Even if it only helps performance a little bit.

In Punycode.js for example, at some point I need to check if a given BMP code point (guaranteed to be in the range from `0x0000` to `0xFFFF`) is a low surrogate (i.e. in the range from `0xDC00` to `0xDFFF`) or not. You could use the following piece of code for that:

codePoint >= 0xDC00 && codePoint <= 0xDFFF

The following has the exact same effect for all BMP code points, but is much more efficient:

(codePoint & 0xFC00) == 0xDC00

It’s not as readable as the first option, but it does the job and it’s faster. Speed is more important for a drop-in library IMHO.

OTOH, for code that is developed in a team, it’s probably not a very good idea to ‘obfuscate’ the source like this in the name of performance. Sure, there might be a run-time performance gain of a few nanoseconds, but you’ll probably end up confusing your colleagues and wasting minutes of developer time.

I also prefer checking for odd/even numbers with “num & 1” instead of math modulo, or switcher variables with “number ^= 1” instead of setting a boolean to true or false explicitly.

Infact, I truly believe bitwise operators used in the rights spots are very convinient and useful at the same time (the performance gain is just sugar on top)