Stack Overflow上最火的答案居然有Bug?

最近，一位叫做 Aioobe 的开发者在一项调查中,发现了一段自己十年前写在Stack Overflow 上复制次数最多、传播范围最广的代码，其实是有 bug 的。

十年后的今天发现，这段代码居然有bug？

这段代码是什么？

即如何以人类可读的格式输出字节数？

举个例子，将“123456789 字节”转换为“123.5 MB”的格式输出。

这里的隐含范式在于所得到的字符串值应该在 1 到 999.9 之间，后面再跟上一个大小合适的单位。

以循环为基础，基本思路非常简单：尝试所有单位，从最大（EB，即 1018 字节）到最小（B，即 1 字节），而后使用一种显示数量小于实际字节数量的单位。

用伪代码写出来，基本是这么个意思：

无论是 KB、MB 还是 GB，所有单位的本质实际都是 1000 的幂（当然，按 IEC 标准来讲是 1024），意味着应该可以使用对数而非循环来计算正确的量级单位。

基于以上思路，修改答案为：

当然，这段代码可读性不高，而且 log/pow 也可能在一定程度上影响执行效率，但至少这里没有循环，几乎不涉及分支，所以还是比较整洁的。

但回答者也没想到，这段代码会成为Stack Overflow 上复制最多的代码片段。

BUG 在哪？

看不懂的小伙伴，往下拉。

在 EB，即 1018 之后，接下来的单位应该是 ZB，即 1021。

难道是输入量过大导致“kMGTPE”字符串的索引超出范围？不是的，long 的最大值是 263 - 1 ≈ 9.2 × 1018，因此任何 long 值都不会超出 EB 范围。

那么，是 SI 与二进制之间存在混杂吗？也不是。答案的早期版本中确实有这个问题，但很快就得到了修复。

那么，是不是 exp 可以为 0 会导致 charAt(exp-1) 发生错误？不是的。第一个 if 语句也涵盖了这种情况，因此 exp 值将始终至少为 1。

那就只剩最后一种情况了，输出结果中是否存在某些奇怪的舍入错误？这正是我们接下来要讨论的部分……

太多个9

这套解决方案一直运作良好，直到字节数量达到 1 MB。

假定输入为 999999 字节，那么结果（在 SI 模式下）将为“1000.0 kB”。

尽管 999999 比 999.9 x 10001 更接近于 1000 x 10001，但根据规范，1000 的“有效位数”超出了范围。正确的结果应该是“1.0 MB”。

最终版本：

这段代码被复制到了哪里？

2018年，一位名叫 Sebastian Baltes 的博士生发表了一篇论文，标题为《GitHub 项目中 Stack Overflow 代码片段的用法与归因》。

文章探讨的核心议题：

用户对代码片段的引用是否遵循 Stack Overflow 的 CC BY-SA 3.0 许可，即从 Stack Overflow 上复制代码时，用户应保证何等程度的归因水平？

在分析当中，作者从 Stack Overflow 数据转储中提取出代码片段，并将其与公共 GitHub 存储库中的代码进行匹配。

截至目前，这条答案获得了几十万次查看外加一千多个好评。

这也就意味着，这段有问题的代码被无数的项目和开发者引用。

真是ctrl c / v一时爽，众所周知，直接复制粘贴代码并不安全，但还是会有很多小伙伴继续这么做，甚至都不会去追溯代码的来源。

小伙伴们要明白，软件开发绝不是堆砌代码。

软件开发需要：需求分析、架构、设计、编程、测试。

我们单单放大编程这一环节，需要敲代码、调试、分析问题、寻找答案、解决问题。

所以除了敲代码以外，小伙伴们更需要的，还有自己各方面的综合职业能力。