为什么Object.hashCode（）不遵循Java代码约定

我认为它确实遵循惯例。这完全取决于您正在谈论的约定。

OP对Java编程语言的代码约定特别感兴趣，第9章介绍了方法名称的约定。首先，应该注意的是，该文档已不再维护，包含大量警告：

...信息本身可能不再有效。本文档的最新修订时间为1999年4月20日

当然，该hashCode()方法早于1999年，因此我们可以参考文档以查看所讨论的方法是否当时违反了约定。该文件指出：

方法应为动词，首字母小写混合，每个内部单词的首字母大写。

关于hashCode()，没有争议的是首字母小写是混合大小写。但是，OP似乎认为它违反了方法应为动词的约定；隐含的假设是“哈希码”或“哈希码”是一个名词。

在做出判断之前，让我们看一下约定的第三部分：每个内部单词的第一个字母都大写。如果您简短地假设原始作者遵循这些约定，则大写的hashCode()表示其作者将“哈希”和“代码”视为单独的单词。如果分别对待它们，则“哈希”一词是英语中的动词。通过这种解释，可以满足公约的所有部分。

公认的是，“哈希码”一词已成为（至少）Java开发人员中的通用术语，并且通常被视为名词-可能在很大程度上由于该方法的名称而很少。（鸡诉蛋？），但只有原来的作者可以自己说话的意图。

在我的原始答案中，我使用JavaBeans约定作为示例：

Bean是Java类，其方法名称遵循JavaBeans准则。Bean构建器工具使用自省检查Bean类。基于此检查，Bean Builder工具可以确定Bean的属性，方法和事件。

在JavaBeans中，属性是通过“ getter”方法访问的，即，通过调用来读取“ foo”属性getFoo()。但是，该hashCode()方法是Java语言对所有子类的技术要求，Object但通常不是对象表示的“业务逻辑”的属性。如果你写一个类来表示水果，那就样特性getColor()，isSkinEdible()等等。如果不是因为Java的技术要求，你可能不会考虑写等的方法getHashCode()，因为......你有没有发现一个活生生的香蕉哈希码？

如果hashCode()命名为getHashCode()then，则根据该约定，JavaBeans必须对其进行特殊处理才能忽略它。否则，它将始终检查该“属性”以查找程序的主要逻辑中通常很少使用的内容。

我无法在此答案中涵盖所有可能的约定，但是我对问题中给出的其他示例有这些想法：

• createHashCode()-即使按照约定，我也不会使用它，因为hashCode()返回一个int（原语）并且它们的创建方式不像引用类型（对象）那样。我认为这是错误的动词。

• toHashCode()-对我来说，这代表着一种转换。但这不是什么hashCode()。如果foo.hashCode()返回的话，42我不会有42任何表示形式的期望foo。它是根据有关foo实例的信息计算得出的，但没有其他实际的相关性。许多其他实例（许多类）可能会返回，42因此不是任何实例的替代品或类似物。