意外的惊喜

当那个玩笑般的API坑了你

尊敬的KV，

最近在工作中一个小型项目需要我使用JavaScript，我很惊讶地在设置超时代码的文档中发现了以下注释

另请注意，如果该值不是数字，则会对该值进行隐式类型强制转换以将其转换为数字——这可能会导致意想不到的惊人结果；有关示例，请参阅非数字延迟值被静默强制转换为数字。

通常认为像JavaScript和其他语言会进行鸭子类型，其中类型是隐含的，但这似乎更进一步，将任何输入强制转换为数字。我的代码不允许用户输入进入超时例程，所以我并没有完全吓坏，但是文档的这一点让我停了下来。我无法想象有什么好的理由这样做。

被强制转换的

尊敬的被强制转换的，

至少他们告诉你结果可能会令人惊讶，而且每个人都喜欢惊喜，不是吗？

和您一样，KV也很困惑，不明白这种类型的强制转换与鸭子类型有什么相似之处。为了确保这一点，我找到了您提到的文档，而吸引我眼球的是这个

时间，以毫秒为单位，计时器应在执行指定的函数或代码之前等待的时间。如果省略此参数，则使用值0，这意味着“立即”执行，或者更准确地说，在下一个事件周期中执行。

现在，我们知道预期的参数是以毫秒为单位的时间，我不知道您怎么样，但我从未见过这样的时间以整数以外的任何形式表示——您知道，像42。为什么会有人提供数字以外的任何东西呢？

事实证明，JavaScript也传递了很多字符串，或者人们可能会从阅读这份滑稽的文档中想到。事实证明，字符串“1000”与数字1,000相同，这是一种有用的强制转换，但是字符串“1 second”被转换为0，因为，嗯，只是因为。

在我看来，也许在您看来也是如此，真的应该在此处标记一个错误。如果您想要一个数字，但得到的是一个字符串，那就说出来，而不是仅仅“试图做正确的事情”，特别是如果做错的结果可能会令人惊讶。KV不喜欢惊喜，并且非常讨厌代码中的惊喜。

这个API另一个有趣的部分是，正如您指出的，如果它接受用户输入会发生什么。想象一下，一个银行网站让您告诉它您想等待代理回电多长时间，并且在输入框后面有这个玩笑般的API。有多少人会写“1 second”或“1 minute”，或者一些其他将被强制转换为0的值？

这里有一个更高层次的问题，即具有强制转换的弱类型语言从一开始是否真的是一个好主意。如果您不知道您正在操作什么，或者预期的输出范围可能是多少，那么也许您一开始就不应该操作该数据。但是现在这些语言已经进入了野外，我们永远无法足够快地找到它们并将它们杀死，这既是为了我的喜好，也是为了更大的利益。

我们现在唯一的补救措施是在这些API周围设置我们自己的保护措施，并确保我们知道我们正在传递什么，以免我们最终站在强制转换的错误一边。

George V. Neville-Neil 以网络和操作系统代码为乐，并以此营利。他还教授与编程相关的各种主题的课程。他的兴趣领域是计算机安全、操作系统、网络、时间协议以及大型代码库的维护和管理。他是The Kollected Kode Vicious的作者，并与Marshall Kirk McKusick和Robert N. M. Watson合著了The Design and Implementation of the FreeBSD Operating System。近20年来，他一直是专栏作家，更广为人知的名字是Kode Vicious。自2014年以来，他一直是剑桥大学的工业访问学者，在那里他参与了几个与计算机安全相关的项目。他获得了马萨诸塞州波士顿东北大学计算机科学学士学位，并且是、Usenix协会和IEEE的成员。他的软件不仅在地球上运行，而且还作为VxWorks的一部分部署在NASA的火星任务中。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。

最初发表于Queue 第22卷，第4期—
在数字图书馆中评论本文

更多相关文章

Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全要求的考虑，存在许多用于加密哈希的标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
DevEx（开发者体验）在许多软件组织中越来越受到关注，因为领导者寻求在财政紧缩和人工智能等转型技术的背景下优化软件交付。直观地看，技术领导者普遍认为，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进DevEx的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，以研究生产力差异，从而提供关于该主题的新见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性以及未来研究的机会。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。在追求快速前进的匆忙中，它容易受到时尚的异想天开的影响，并且可能会忘记或忽略已经过验证的解决方案来解决它所面临的一些永恒的问题。用例，最初于1986年引入，后来普及开来，就是这些经过验证的解决方案之一。