《由 indexOf 引发的对于 “~” 的思考》

场景

当编写业务代码时，通常会用到 indexOf 来判断 target 是否在 source 中类似的问题。

那么最通常的做法是：

const index = source.indexOf(target);

if (index !== -1) {
  // 存在 target 的限定条件执行的逻辑
} else {
  // 不存在 target 的限定条件执行的逻辑
}

如何让类似的代码被写得很优雅？使用位运算的取反（~）操作！先来看下如下代码：

if(~source.indexOf(target)) {
  // 存在 target 的限定条件执行的逻辑
} else {
  // 不存在 target 的限定条件执行的逻辑
}

仅通过一个 “~” 符号就可以完成判断。那么这么写的依据是什么呢？

依据主要有两个：

1. 位运算 ~；
2. 隐式转换；

隐式转换

具体隐式转换规则可参考我的这篇文章。

位运算 ~

前提：我之前一直很困惑，JavaScript 的数字 Number 类型在计算机中是以多少位进行存储的呢。

JavaScript 采用“IEEE 754 标准定义的双精度64位格式”（“double-precision 64-bit format IEEE 754 values”）表示数字。

原来，JavaScript 在计算机中主要是以双精度 64 位浮点型格式表示 Number 类型，但是在进行位运算（数组索引等）操作的时候是以 32 位有符号位的二进制进行计算的。

这也是为什么 JS 关于小数计算的问题上总是会有丢失精度的问题。

位运算 ~ 取反操作是将二进制数字按位取反，但是因为二进制数字是有符号位的，因此在取反的过程中，符号位也被取反了。

举个🌰：

Q. 对数字 0 进行取反操作，最终得到的数字是？即 ~0 => ?。

// ~0:
  // 先将数字 0 转换为 32 位的二进制（A)：0000 0000 0000 0000 0000 0000 0000 0000
  // 然后对二进制 A 进行取反得到二进制（B）：~(0000 0000 0000 0000 0000 0000 0000 0000) => 1111 1111 1111 1111 1111 1111 1111 1111
  // 由于有符号位的二进制的符号位位于从右往左的最后一位（31位），如果为 1 则表示负数，如果为 0 则表示正数
  // 二进制 B 的第 31 位是 1，因此当前二进制表示的负数，那么要求出最后的负数是多少，则需要进行逆向转换补码
  // 补码的具体步骤就是负数绝对值的二进制按位取反，然后加 1，得到的二进制数就是当前负数在计算机中的表示（不太清楚的小伙伴请参考上文）
  // 那么我们将二进制 B 减 1 然后再取反，就能得到当前负数的绝对值了
  // 1111 1111 1111 1111 1111 1111 1111 1111 - 1 => 1111 1111 1111 1111 1111 1111 1111 1110 => ~(1111 1111 1111 1111 1111 1111 1111 1110) => 0000 0000 0000 0000 0000 0000 0000 0001 => 1
  // 绝对值为 1 的负数很显然，就是 -1。

那么通过大量的测试，可以总结出来：一个数的取反操作最终对应的数字就是当前数的负数 - 1（同样对应负数）。

总结

回到业务场景，~source.indexOf(target)

• 如果 indexOf 返回得是 -1，那么经过取反操作，会返回 0，而 0 被隐式转换后得到 Boolean 类型的值是 false；
• 如果 indexOf 返回得不等于 -1，那么经过取反操作后不会得到 0，而非 0 值被隐式转换后得到 Boolean 类型的值均是 true；