编译器警告

许多编译器都有警告消息来警告程序员有关潜在的运行时，逻辑和性能错误，大多数情况下，您可以快速修复它们，但是不可修复的警告呢？

您如何处理不可修复的警告？您是重写代码的一部分，还是以“漫长而无用的方式”重写代码，还是一起禁用警告？最佳做法应该是什么？

如果您正在编辑别人的代码并且他的代码有警告，该怎么办？

这是一个很好的例子：由于检测到Mozilla类浏览器，jQuery有很多JavaScript警告，为什么jQ开发人员不解决这些警告？如果您对jQuery有所贡献，您是否会解决它们？

通常可以放心地忽略一些警告，但是如果您这样做，随着时间的流逝，它们会不断增加，直到那天到来的时候，您会错过很多真正重要的警告，因为它被隐藏在噪音中了。

修复警告立即（其中可能包括，如果你觉得它的禁用单独的规则从来有关你的情况下）。

我的意见是，你应该对自己严格。该编译器由该语言的专家共同编写。如果他们报告有些不舒服（认为代码有异味），则应检查代码。

完全有可能编写无错误且无警告地编译的代码。

当我用C和C ++编写代码时，我会启用最严格的设置，因为我想知道什么时候对编译器没有意义。当我完成转换并检查返回值时，我会很高兴，因为代码是我所能做到的正确的代码。

我偶尔会从其他人那里得到会发出警告的代码。检查源代码表明，他们忽略了C中良好的编程习惯，从而使代码易碎。

因此，我认为有充分的理由来保证严格性并花时间修复问题。否则是草率的。如果我有一个关闭警告的同事，我会花一些时间和他们以及经理一起解释为什么这是一件很糟糕的事情。

我会修正任何警告。如果您忽略它们并让它们积累，您实际上可能会错过一些重要的事情。

通常，您应该努力使编译器保持沉默，以便更多地显示新的警告。这些警告可能表示细微的错误，应相应地进行处理。

关于修改其他人的代码，这在很大程度上取决于您的工作场所文化和代码的当前状态。如果代码触发了完整的重新测试周期，则您不能仅仅更改代码，就像在测试阶段或生产中后期使用代码一样。

问你的老板，并采取相应的行动。

每次看到编译器警告时，您都必须停下来想一想，这是否真的是一个问题，等到客户现场出现问题时，还是可以忽略的问题。更糟糕的是，在看似无关的代码更改“ Somewhere Else”之后，您今天可能会忽略的事情可能会在几年后在客户站点上爆炸。

修正警告。期。就是记录或记录其中的每一个，并提供足够多的页面说明，以证明这不是风险，并在您最爱的女友（或色情收藏）上签署一份销售订单，如果事实证明如此，有风险。

通常，您希望构建不受警告。出现警告是有原因的，并且警告的确经常指出非常实际的问题。如果您习惯于忽略编译器警告，则最终您的构建中将包含大量警告，并且您将错过由灾难性问题引起的警告，这将使您的公司付出沉重的代价。另一方面，如果您的程序正常编译时没有警告，则每个新警告都会立即被注意到，并可以迅速得到解决。

话虽这么说，有时编译器可能会有一些毫无意义的警告，并且无法轻易解决。我每天都在与TI CodeComposer一起工作时面对这种情况，TI CodeComposer是TI DSP的开发环境。我有C ++代码，在Visual Studio下不会发出任何警告，但会在CodeComposer中产生奇怪的警告，这仅仅是因为TI对标准C ++的支持会更好。幸运的是，CodeComposer允许您分别禁用特定的警告，这是当我们无法修复产生警告的代码时必须要做的。

就我而言，警告来自PyLint工具，我可以通过在注释中添加特殊文本来禁用特定行的警告。

在大多数情况下，我不这样做。在大多数情况下，我更改代码以遵循PyLint的建议，因为PyLint通常是正确的。但是，在不喜欢的情况下，构造通常不是一个好主意，但是在特定情况下才有意义。例如，它抱怨我是否捕获了所有可能的异常。通常，这是正确的，这将是一个坏主意。但是，在某些情况下，我确实希望捕获所有异常，例如向自己发送包含详细信息的错误报告。

所以：几乎在所有情况下，都摆脱不了黑客。当黑客确实有道理时，请添加一条评论，告诉PyLint可以。

其他答案中并未明确指出严格性的一些好处：

1. 修复所有容易解决的警告后，剩下的重要/相关警告更有可能显示。
2. 如果发现了相关的警告并按时（发布前）进行了处理，则可以避免错误，从而使最终用户更加满意
3. 解决警告通常会导致代码更易于维护和简化（例如，消除始终为真的条件）
4. 当警告数量接近于0时，团队中的零警告策略很容易达成共识，这在CI系统中很容易实现自动化。
5. 解决编译器警告时，加深对程序代码的理解，这可能会导致对实现的有用见解（例如，发现其他错误或获得有关如何进一步开发代码的想法）
6. 构建速度更快，每日生产率提高：IDE /编译器管理和报告的问题更少，因此编译速度更快（这仅在成千上万的警告情况下才有意义）。

某些警告在语言上有所不同。我认为，就该主题进行思考和讨论，然后禁用一些单独的警告（如果它们觉得完全没有用），则很重要，这样才能实现严格性。在我的职业生涯中，已经有多个团队实现了这一目标。有关该主题的更多经验

警告和错误是编译器用来告诉程序员“您写的东西没有道理”的消息-它们之间的区别在于，发出警告时，编译器愿意猜测程序员的意图，而出现错误时，编译器甚至无法猜测。

编译器错误将得到解决（我不会说是fixed），但是程序员（甚至是经验丰富的程序员）经常会忽略警告。忽略警告的问题是，有时编译器会猜测错误，并且如果您有1000条以上的警告消息，则很容易错过一条警告消息，表明编译器在猜测错误。

从社会学的角度来看，具有许多警告消息的程序是“ 破碎的Windows”。