当没有匹配的元素时，为什么要列出#indexof返回-1？

Question

最近，我正在阅读Java集合框架的源代码，注意到了List#indexOf方法。

在这个方法的Javadoc中，它说“返回指定元素在这个列表中第一次出现的索引，或者如果这个列表不包含该元素，-1。”

我很好奇为什么它应该返回-1确切地说...仅仅返回一个负数就足以满足要求，以下是我的观点：

1. 比较数字是否为负比比较数字是否为-1容易。
   （确定数字是否为负只能比较符号位）
2. 如果允许为“未找到元素”返回负值，则可能有助于优化某些特殊的数据结构。

我已经在谷歌上搜索过了，但似乎没有人有和我一样的困惑……
谢谢你的回答:)，我是一个Java的呆子&所以……

Answer 1

比较一个数字是否为负数比比较一个数字是否为-1更容易

你想错了。考虑波斯特定律：

接受的东西要自由，送的东西要保守。

并将其应用于API设计。

你可以自由地写：

if (list.indexOf(something) < 0) ....

它每次都起作用，因为-1是一个负数。

将API写成“任何负数”有什么可能呢？

让我们一起来了解一下：

>

它在文档中建议API的用户应该编写<0而不是！=-1-但这并不是一个很大的论点：您最多可以这样说，文档可以说尽管始终返回-1，但API的用户应该使用<0进行检查。但这是荒谬的：正确的检查方法是根本不调用indexof而是调用.contains()。

它使编写调用.indexof的代码变得更加容易。这是false-您可以同样编写<0。在需要索引稳定的地方，可能会出现这种情况（假设您将一些数据存储在java.util.map 集合中，您的过程是在列表中查找某个键以计算id（一个整数），然后将其映射，您还需要将“key not found”映射到某个东西。如果.indexOf()被指定为返回任何负数以表示未找到，则您必须将该数据“清除”为-1，但您不必这样做，它保证为-1。

它使得编写java.util.list的实现更加容易。这似乎是一个无关紧要的争论（您多久实现一次J.U.List？不像调用它那样每天都发生）。我很怀疑它实际上会导致更短的代码，我真的怀疑代码会更易读。

那么，有什么可能的点呢？

记住，这是一个API规范。并不是每一个决策都需要一个解释，除了“我们需要一些特定的东西，因为API的目的是命令公共的规则集”。有时只是选择任何东西就是主要的胜利，在许多相同的选择中选择哪一个并没有多大的关系。只要每个人都同意使用相同的选择，就可以了。这就解释了为什么它是-1，而不是-100或integer.min_value(-2^31)。他们本可以选的。他们没有。-1稍微简单一些（编写-1要比integer.min_value简单一些，它是“第一个”负值，并且在某种程度上与已建立的约定相匹配，例如各种C库返回-1表示未找到。