避免警告和通知是一种好习惯吗？

通常，我一直在处理PHP警告和注意事项，因为我从事的许多项目已经在实时生产中。现在，如果我打开这些实时生产网站上的警告和通知，它们将被超负荷使用。

我在家中或本地进行的项目通常会尝试消除所有警告和注意事项。有时，没有通知是没有解决方案的，所以我只需要处理一下通知，直到决定完全关闭通知。

最后，我不知道我是在浪费时间试图摆脱所有警告和注意，还是为了更大的利益而这样做。

因此，我的问题是，完全避免发出警告和通知是一种好的做法，还是真的没有关系？

如果我打开这些实时制作网站上的警告和通知，它们将被超载。

在开发，测试和质量检查中，应该始终将警告最大化，而不是在生产中。实际上，如果这是一个令人讨厌的应用程序，即您自己使用的应用程序，则还应该在生产中将其打开。

基本上：在看到他们的人有能力对其进行处理的情况下将它们打开（开发和测试的开发人员可以自己修复它们，QA中的测试人员可以提交错误，并且如果开发人员可以也是用户，那么他也可以在生产环境中进行修复），但是当看到的人对他们无能为力时（生产用户甚至不知道如何编程），都不要打开它们。

理想情况下，您还希望将警告视为错误，但这仅在没有开头的情况下才有效;-)但请记住这一点作为目标！如果可以按文件打开/关闭此功能，请为所有新文件将其打开，然后为所有无警告的文件将其打开，并且永远不要再次将其关闭。

那么，如何处理过载？

您列出所有警告和注意事项的列表，然后遵守以下规则：

1. 永远不要在任何情况下都不会在列表中添加新的警告。每个新的代码段，每个编辑，每个更改，每个补丁，每个提交都不得引入新的警告，它只能修复它们。
2. 每当您触摸一段代码时，请修复该代码段中的所有警告。（Boyscout规则：始终使营地处于比您发现的状态更好的状态。）这样，不重要的代码可能会充满警告，但是重要的代码会随着时间的流逝变得更干净。“代码段”可以是函数，类，文件。您也可以放宽此规则，说至少要修正一个警告。关键是：在找到它们时对其进行修复。

注意：这两个都要求您拥有某种日志数据库和日志过滤机制。还要注意，“日志数据库”和“日志过滤机制”可能只是一个文本文件和grep。

这是重要的一点。没有数据库，您将不知道何时添加新警告，没有过滤，您仍然会遇到过载问题。

注意＃2：这不仅适用于警告，还适用于样式检查器，复杂性指标，代码覆盖率，静态分析工具等。基本上：

1. 不要添加新问题。
2. 当您发现旧问题时，请进行修复。

这使您可以轻松地确定优先级：经常编辑并因此需要易于阅读和维护的代码将随着时间的流逝而变得更好。不会经常被触及的代码不会变得更好，但这没关系，因为无论如何也没有人需要看它。而且，至少它不会恶化。

当然，没有什么可以阻止您专门分配时间，以便无所事事地追捕并杀死警告。只是这种情况在经济上不可行，而作为工程师，您要牢记这一点。“工程师是一个可以用一美元建造的工程师，任何傻瓜都可以用两个建造的工程师。”

如果警告和通知来自您的代码，则绝对可以修复它。根据我的经验，有95％的人可能是良性的，但有5％的人强调一个真正的问题，这可能会导致花费大量时间进行追逐。

如果它们来自您出于某种原因而必须使用的第三方代码，则通常没有太多选择。

如果您的遗留代码库确实很大，这是一个不同的问题，那么您可以将遗留代码视为第三方，但是要求新代码必须没有警告。

这很重要。警告可能不会破坏您的测试，甚至不会在野外出现一段时间-但这可能是隐隐可见的错误的征兆。我目前主要使用C＃/ C ++进行开发，并且具有定义的策略来摆脱和避免在我们的代码库中发出警告。幸运的是，这不是火箭科学。

如果您使用的语言能够将警告视为错误并且具有不同的警告级别，我将执行以下操作：

1. 将警告级别调低到足够远，这样您就不会收到任何警告。如果您处于最低警告级别，但仍收到警告-尝试修复它们。如果您不能修复它们，那么您现在就完成了，但是希望您可以修复它们。大。
2. 由于您现在没有警告（很可能处于低警告级别），因此请拨动开关并将所有警告视为错误。
3. 尝试提高警告级别并修复所有新警告。如果不能，请调低警告级别，但不要关闭警告，将警告视为错误。

我发现这不仅可以在我的代码中显示警告，还可以将警告排除在外。