我如何说服队友不要忽略编译器警告？

我使用eclipse在Java中进行了一个大型项目（更像是数十个小型项目的混乱组合，由于依赖管理不善而无法轻易分离，但这是另一回事）。我们已经从编译器设置中关闭了许多警告，并且该项目仍然有10,000多个警告。

我强烈建议尝试解决所有警告，并尽可能修复所有警告，对于被调查并认为安全的警告，请予以压制。（我对将所有已实现/重写的方法标记为@Override的信仰也是如此）。我最大的论点是，一般而言，警告可以帮助您在编译时发现潜在的错误。也许在100次中的99次中，警告是微不足道的，但是我认为它为防止重大错误而节省了一次，这是值得的。（我的另一个原因是我的代码清洁度很强。）

但是，我的很多队友似乎都不在乎。当我偶然发现警告时，我有时会修复（但是当您触摸同事编写的代码时，您会发现这很棘手）。现在，警告实际上比类多，警告的优势已大大减少，因为当警告如此普遍时，没有人会费心地查看所有警告。

我该如何说服我的队友（或潜在的力量）警告需要被解决（或在充分调查后被取消）？还是我应该说服自己疯了？

谢谢

（PS我忘记提了，最后促使我发布此问题的原因是，我可悲地注意到我修复警告的速度比发出警告的速度慢）

您可以做两件事。

1. 指出警告是有原因的。编译器作者之所以放手是因为他们刻薄。我们行业中的人们通常会有所帮助。许多警告是有帮助的。

2. 收集由忽略警告引起的重大故障的历史。在网络上搜索“注意编译器警告”会返回一些轶事。

您的痴迷@Override不是“痴迷”。这是一件好事。是否曾经拼错方法名称？

相关阅读这里。C ++，但仍然相关。我特别喜欢这个例子（代码注释是我的）：

int searchArray(int to_search[], int len, int to_find)
{
    int i;
    for( i = 0; i < len; ++i )
    {       
        if ( to_search[i] == to_find )
        {
            return i;
        }
    }
    // should be returning designated 'not found' value (0, -1, etc)
}

在许多情况下，警告意味着应用程序崩溃并出现错误，这实际上可以帮助您查找设计缺陷并进行修复（例如安全的类型转换），或者由应用程序做出假设，然后实际表现出错误，或错误的方式（不安全的类型转换就是这种情况）。类似地，它们还指出可以删除的原始代码或死代码（无法访问的代码块，未使用的变量），这些代码可以视为代码优化或无法解释的情况，这些情况将在测试中显示出来，例如上述C ++示例。请注意，此示例在Java中导致编译时错误。

因此，解决警告问题（至少）具有管理方面的多个优点：

1. 代码对用户输入的数据进行不当行为的可能性较小，对于上级关注公司形象及其如何处理客户数据的高层人士来说，这应该是一个大问题。进行崩溃以防止用户做傻事总比不崩溃并让他们去做更好。
2. 如果他们想对人员进行改组，人们可以进入无警告的代码库中（而不必大惊小怪或抱怨太多。）。也许这将减少抱怨的数量，或者减少对X团队对Y计划的贡献的可维护性或质量的意见。
3. 通过消除编译器警告来优化代码，尽管不会显着改善运行时间，但在测试方面将提高许多分数：
   • 任何代码覆盖率得分都可能会增加。
   • 测试边界和无效测试用例可能会更频繁地成功（由于上述安全类型转换等原因）。
   • 当测试用例确实失败时，您不必考虑它是否是由于该源文件中的编译器警告之一引起的。
   • 零的编译器警告比数千的警告好是很容易争论的。没有警告或错误说明代码的质量，因此您可以说代码质量可以改善警告的数量。
4. 如果没有编译器警告，并且引入了一个或多个警告，则更容易知道是谁导致这些警告出现在代码库中。如果您有“无警告”政策，那将有助于他们识别出工作做得不好的人，也许吗？编写代码并不只是做一些工作，这是关于使其工作良好。

请注意，我仍然只是一个初级开发人员，对项目管理知之甚少，因此，如果我说错了什么，请纠正我的想法，并给我一个编辑的机会，然后再拒绝我的存在:)

我过去从事过具有类似特征的项目。特别地，这最初是用Java 1.4编写的。带有泛型的Java 5发布之后，您可以想象编译器针对Collections API的每种用法抛出的警告数量。

通过开始使用泛型，要花掉一些时间才能消除所有警告。这是一个必须考虑的因素，但是当您必须说服某人（尤其是您的经理）需要修复时，您将需要硬数据，例如

可以避免的传统或非标准兼容代码（该标准是项目的编码标准）中的错误所花费的时间。

您可以继续提出一项法案，通过忽略“某些”警告来演示您如何浪费时间和金钱，然后有人会想到这个。关键部分在于，并非所有警告都值得关注，至少不是马上就值得关注。用简单的话来说，您将需要确定需要立即解决的警告的优先级。首先，考虑与您在项目中看到的错误相关的错误。

在修复错误时，您还可以在错误跟踪器中进行记录，可以通过不忽略警告（或者如果具有CI或构建系统，则可以通过运行PMD或FindBugs）来避免该错误。只要有足够数量的错误可以通过注意编译器警告来解决，那么有关查看编译器警告的观点将是有效的。否则，这是一个商业决策，通常不值得花时间进行这场战斗。

如果您成功了，并且您的团队决定遵守警告，那么您应该采取逐步的方法。没有人可以并且一次会发出10000条警告。因此，您可以选择最重要的错误（那些是很有可能发生的错误），并禁用不重要的错误。如果已修复，请再次提高警告级别。另外，您可以从FindBugs开始，它会警告几乎总是错误的代码。

我完全同意您的观点，最好的做法是尽可能多地清理编译警告。您提到您的团队正在使用Eclipse作为开发工具。Eclipse是一个非常好的工具，可以帮助您清理代码并保持代码样式的一致性。

1. 为每个Java项目定义“保存操作”，例如格式化代码，未使用的局部变量，组织导入（我认为没有人反对这种清理）。
2. 为每个项目定义项目特定的编译选项。例如，编译级别（如果您的代码需要与1.4兼容以清除与泛型相关的警告），则赋值无效（例如'x = x'），依此类推。您和您的队友可以就这些项目达成协议，并且在您同意编译错误之后，Eclipse将在开发阶段将其报告为“错误”。

Eclipse将在.settings文件夹下为这些首选项创建一些属性文件，您可以将它们复制到其他Java项目中，并将它们作为源代码的一部分检入SCM。

您可以查看Eclipse的代码，以了解Eclipse开发人员是如何做到的。

您有两种消除所有警告的方式（我同意它可以隐藏一个细微的错误）：

1. 说服整个团队这是最好的做法，并让他们进行修复。
2. 说服您的老板这是最好的做法，并将其强制执行。然后，他们需要修复它。

我认为1在您的情况下不再可行。同样，由于将在生产力输出中显示警告的数量，这可能会花费很长时间，因此管理层无论如何都需要知道。

因此，我的建议是：与老板讨论，说服他这是一颗滴答滴答的炸弹，并制定了官方政策。

我只想告诉他们，大多数警告都是微不足道的警告，因此必须将它们从列表中删除。这样我们就不会错过人群中真正的重大警告！

您需要耐心尝试说服他们，在进行配对编程时删除警告会帮助其他人养成习惯。建议他们阅读有效的Java“第24项：消除未经检查的警告”（针对通用集合）。并且可能会忽略许多人们不听从您的建议的情况；）

一种有效的方法是设置一个持续集成服务器，该服务器可以在任何人签入代码时自动构建项目并运行测试。如果您还没有使用它，那么应该使用它，并且很难说服其他人这样做的好处。

1. 令人信服的管理人员/团队领导这样做的好处（防止部署不良构建，及早发现错误，尤其是那些意外影响软件其他部分的错误，维持回归测试，及早且经常进行测试等）

2. 在所有测试通过的情况下安装CI服务器（如果您没有测试，请编写一个快速通过的测试，以便每个人都看到它是绿色的）。

3. 设置有关每个构建状态的电子邮件或其他通知。在这里重要的是要包括谁签入了代码，进行了什么更改（或指向提交的链接）以及构建的状态+输出。这是重要的一步，因为它可以为成功和失败带来整个团队的可见性。

4. 如果有任何警告，请更新CI服务器以使测试失败。管理层和团队负责人将看到，这以系统的方式增强了团队的纪律性，没有人愿意对所有失败的电子邮件负责。

5. （可选）通过添加一些可见的仪表板，熔岩灯，闪光灯等来表明构建的状态以及破坏它的人/修复它，从而使它变得美观。