修复所有警告和错误：此代码质量策略的历史是什么？

#1 楼

史蒂夫·麦康奈尔（Steve McConnell）在Code Complete（1993）中写道：消除所有编译器错误和警告的原因。请注意编译器告诉您的代码。许多警告通常表示代码质量低下，因此您应该尝试理解收到的每个警告。在实践中，您一次又一次看到的警告具有两种可能的影响之一：您忽略它们，它们伪装了其他更重要的警告，或者变得像中国的酷刑一样令人讨厌。 > p664：


将编译器的警告级别设置为最高，最挑剔的级别，并修复代码，以使其不产生任何警告。忽略编译器错误很草率。关闭警告甚至更草率，以至您甚至都看不到它们。

#2 楼

我可能首先在perl社区中遇到此问题，在该社区中使用警告的建议“全部”；并使用严格；很常见。我的猜测是，我首先在Randal Schwartz的“有效的Perl编程”中阅读了该书-看起来像在146页上。那本书出版于1998年。针对尖头程序和小型程序的方法，以及一些大型但批处理模式（“ IT商店处理”）应用程序。我会注意以下几点：

1）这使您非常依赖于代码库。如果您使用引发警告和错误的库，则可能会引起麻烦。 （我可以使用该术语，基本上是我的姓氏。）

2）这也使您非常依赖于基础结构。如果您不想在服务器日志中看到任何警告和错误，则必须在坚如磐石的技术堆栈上构建坚如磐石的应用程序。例如，这在Ruby On Rails的早期版本中是行不通的-基础软件根本不够坚固。

3）结论：在您小的EDI到EDI转换脚本上，这可能会正常工作。但是，传播的范围越广，传播的内容就越稀薄-在财富500强数据中心中尝试任何错误或警告，并观察能带给您的距离有多远。与我合作过的几乎所有客户都可以从朝这个方向发展中受益。实际上，它们中的大多数都有如此多的错误和警告，它们通常会忽略存在用于监视日志的所有软件类别，并告诉您什么时候不应该真正注意的这一点。其中一些使用AI或机器学习。

在大多数情况下，可以将我们可以忽略的虚假和愚蠢的警告数量减少十倍甚至更多。

这对我的朋友们来说是一个值得接受的挑战。

#3 楼

我完全同意Neils，并且我想解决这个帖子是否属于此Testing网站的问题。

一些基本的测试原理不依赖所使用的语言或开发的应用程序而适用，这些原理之一是：

复杂性使测试更加困难。

面对错误消息的测试人员正在尝试处理额外的不必要的复杂性-要看的东西与测试工作无关。摆脱它们。

一个潜在的反驳：无法清除错误消息通常表示开发人员匆忙编码。匆忙编码是产生编码错误的良方，因此，许多未清除的警告消息可能是测试人员的线索，暗示了潜在的容易出错的代码。

错误书

#4 楼

生成警告的早期工具是Lint。该警告旨在使程序员像对待错误一样对其进行修复。 Lint，一个C程序检查器。计算机科学技术报告65，贝尔实验室，1977年12月。提到的文章没有明确说“修复所有警告”。但是，它建议通过提供一种消除错误警告（由Lint的错误或缺点引起的警告）的方法来实现干净运行的目标，以达到干净运行的目的。 />但是，我不知道是否有较早的工具具有类似的意图。

#5 楼

如果有的话，那就是相反的情况-这种文化开始让错误和警告越来越多地留在其中。卡-程序-很有限，通常很昂贵，而且卡座通常必须经过“验证程序”，检查程序的人会发现错误。即使系统负载很轻，也可能需要一个小时或更长时间才能运行平台，发现错误，修复并重新提交平台。

我从来没有提交过任何会导致错误的内容。

当我在1980年代初学习编程并于1985年开始工作时，打孔卡的日子就快结束了（我打孔并跑了一个牌-

然而，当时的职业中期程序员是从那个背景出发的，每个人都对警告给予了真正的认真对待-您根本就没有把它们留在里面，不用担心错误。遇到必须留下的警告真是令人震惊-而且您该死的人知道该怎么做，为什么不能解决它们以及如何以及为什么它们不会引起问题。 />
，我的意思是，如果警告不是什么意思，为什么还要发出警告？他们经常这样做：警告：进行此无损声明，您将随机覆盖重要的内存位。通过IIRC，Visual C ++在1990年代后期开始出现了许多无用且棘手的警告。我记忆模糊，如果Gnu编译器接受不带警告的警告，则生成Visual C ++警告的构造被认为是可以的。

我仍然对警告有这种感觉。在任何情况下，我都希望通过对代码进行增量测试，方法是将其粘贴到解释器或测试文件中进行编译-因此，如果弹出警告，通常很容易就此消除。 />
我相信亨利·莱德加德（Henry Ledgard）的《编程谚语》或他的后续著作《带样式：编程谚语的Fortran》建议您充分了解您的编程语言，以免产生警告。他曾经是打孔卡程序员。当然，这些天来，挑战在于跟踪您当前正在使用的语言-等待，这是带有“ else：”还是“ else {...}”的语言吗？

#6 楼

我想知道谁先说是否有意义。从历史上看，我希望它能与许多不同的团队在遇到类似问题时出现警告和错误时保持一致，然后再将它们写下来。谁先说的可能是全球不同编程团队中的许多独立人士。我认为这是每个团队最终都会想出的合理规则。

修复所有警告和错误的原因是，如果您不习惯于修复它们，则被他们淹没。可能导致您忽略可能相关的警告和错误。最终，您遇到了生产问题，因为有人长期忽略了它们。最初保留一个或两个警告或错误可能不是问题，但是它可以设置一个不再修复它们的标准。

我发现了一个错误记录系统，有时一个星期记录了20万多个错误。当我们遇到需要调试的问题时，对于开发人员来说，遍历所有这些问题非常令人沮丧。如今，大多数警告都与已弃用的功能有关。如果不尽快删除它们，则无法升级库。可能导致安全问题等。如果您永远无法修复警告（因为警告是可选的），那么您可能会错过重要的警告。这可能永远不会得到优先考虑，因为修复起来既没有乐趣，也没有良好的商业价值。随着时间的推移，可能使混乱变得更大。保持控制似乎是理智的建议：)

清洁代码：

这也可能是倡导干净代码的另一个好时机。干净的代码是人类的代码，而不是计算机的代码。罗伯特·马丁（Robert Martin）建议对代码进行优化以提高可读性，以便其他人可以更轻松地工作。这还有很多其他优点。

警告和错误也是如此。他们不会混淆计算机，它们会很好地处理错误和警告，就像他们会执行混乱的代码一样。问题是警告和错误使人困惑。他们会想知道为什么在这里？我应该用它做什么？谁把它留在这里？是因为原因吗？我也可以忽略它吗？我应该吗？

不要让其他开发人员重复使用。弄清楚意图是什么，并修复警告和错误，以防止造成混淆和不必要的问题。

#7 楼

过去十年中Ruby on Rails历史的一部分是，在一个版本中，经常发生的更改会以弃用警告消息标记，然后在下一版本中完全删除向后兼容性。因此，这个社区中经验丰富的人们已经学会了无视这些警告，后果自负。信号太少，您不知道要注意什么警告-特别是对于刚加入团队的新手。

#8 楼

敏捷开发人员的实践，Subramaniam＆Hunt，2006年。第137页有这个...带有警告的代码检入与带有错误的代码或未通过测试的代码检入一样糟糕。检入的代码不应从构建工具中产生任何警告。例; “稍后会有数十亿行代码”

#9 楼

既然您要求传闻，这与传闻差不多。这是一个非常基于意见的问题。

第一：


修复所有警告和错误。不要容忍任何错误消息



可能不切实际，具体取决于应用程序的大小/范围。某些应用程序有很多很多部分，您/您的团队无法控制所有这些部分。他们会抛出错误/警告，您对此无能为力。

但是，您可以控制以下内容：


，但要在它们出现后立即修复。我强调“它们出现后”，因为这是修复它的最佳和最简单的时间。开发人员将使代码焕然一新，并且修复过程将变得简单快捷。

更重要的是，您是否听说过开发人员说过“我以后要修复”？我有。然后出现代码审查，他们要么没有解决，要么放了一个TODO，但它仍然没有修复。当然，这种情况并非每次都发生，但是它很频繁。因此，我的意思是：应该尽快解决所有警告和错误，因为如果现在还不解决的话，那么它们就可以赢得胜利。不固定。即使在今天看来似乎毫无意义，将来也会有影响。

有人会继承该代码。他们不会知道完整的历史记录，可能会认为这是一个合法的问题。所说的人花时间去寻找一个不存在的错误，因为，让我们面对现实，您太懒了，无法解决良性警告/错误。另外，它们不必要地填满服务器日志，使真正的问题更难发现。