Error-Prone Criteria for new checks

新检查标准

Error Prone为我们提供了强大的工具，禁止某些模式进入我们的Java代码。我们一定要小心使用，以便在不为他们创造繁忙的情况下使用户受益。

默认启用新的Severity.ERROR检查的标准

错误应具有以下属性：

1. 错误应该很容易理解。一旦编译器指出，这个问题应该是显而易见的。
2. 该fix应该很容易做到。例如，“交换这些参数的顺序”或“删除此分号”，而不是“引入新的子类并覆盖方法A，B和C”。
3. 错误应该没有“假阳性”。在任何情况下，检测到的代码实际上不是按照预期工作的。
4. 错误应该表达一个正确性问题。我们希望修复有害的bug，而不是强制执行最佳做法或风格规则。我们不应该鄙视用户的代码。
5. 错误应以小而明显的频率发生。检测到错误从来没有发生过，没有任何意义，但如果错误发生的频率太高，很可能也并没有引起任何真正的问题。我们不想在那些显然“正确”代码上报太多的错误打击人。

最重要的是，当用户看到我们的错误之一时，她应该考虑：“我很高兴错误抓住了我的错误。”

例子

正面例子

ArrayEquals检查标记使用Object.equals方法来做两个数组之间的比较。在这些情况下，意图是比较数组的内容，但是Object.equals却比较了引用的相等性。
一旦解释了这个问题，在程序员实际上并不打算比较引用相等性的情况下，这是一个正确的问题，因为数组内容实际上并没有被比较，这种情况偶尔会发生。

负面例子

考虑使用new Integer（i）的标记，并建议使用Integer.valueOf（i）。这提高了性能，在大多数情况下是正确的。但是，这个错误并不是一个正确性问题，在大多数情况下，性能影响并不重要。
它也经常发生，错误消息可能会使用户烦恼。

考虑一个检查，它检测在所有覆盖其他方法的方法上使用@Override注释。这是我们的风格指南的一部分，但不会自动执行。然而，这不是一个真正的正确性问题，我的直觉是它发生在相当高的频率。
如果这是一个错误则太挑剔了。

启用新的Severity.WARNING检查的标准

注意：这些标准仍在讨论之中。如果您对本主题感到强烈，请随时发送电子邮件至[e-mail]。

警告可能是风格指导违规，潜在的严重错误或性能障碍。有几个原因要发出警告而不是编译器错误。

警告应具有以下属性：

1. 警告应该很容易理解，fix应该是明确的。指出时，问题应该是显而易见的。
2. 警告应该是非常少的“假阳性”。开发人员应该觉得我们至少在90％的时间内指出了一个实际的问题。
3. 警告应该是有潜在影响的事情。我们希望警告足够重要，以便在开发者看到他们时，他们认真对待他们，并经常选择修复它们。
4. 警告应以小而明显的频率发生。检测到从不实际发生的警告没有任何意义，但是如果警告发生的频率太高，那么这可能并不会导致任何真正的问题。我们不想报太多的警告打击人。

他的底线是，当用户看到我们的一个警告时，她应该考虑：“我很高兴编译器指出。”

　参考链接: criteria for new checks