你有没有看过编译器警告列表，是关于坏代码的语句长度，并想到自己：“你知道的，我却是应该做些什么…但我刚才没时间呀？”另外，你是否留意过刚才出现的一条警告，并修复了它？
当我开启一个新项目时，没有警告、没有杂乱、没有问题。但随着代码库的增长，如果我不注意的话，这些杂乱、冗余(cruft)、警告，及问题就会开始堆积。当大量的噪音出现后，从数以百计的、我并不在意的警告中找出那个我却是需要阅读的警告，就会变得更困难。
为了让警告再次有用，我对这些编译产生的警告采取零容忍。哪怕这些警告根本不重要，我都会处理掉。如果不是关键性的，但仍然相关，我也会修复它。如果编译器提示有个潜在空指针的异常，我就从源头修复——哪怕是我明确知道这个问题根本不会出现在生产环境。如果内嵌文档(Javadoc或者similar)引用已经被删除或者重命名，我就会清理文档。
如果有些事情我确实不关系也确实不用操心，那我就问团队是否可以修改我们的警告策略。例如，我发现一个方法的参数和返回值在多数情况下都不会被添加任何值，那我们删除它就不应该得到警告。或者，编程语言升级到新版本后，之前的已经OK的代码也会发出警告。例如，当Java5引入泛型后，老代码中没有特别申明为泛型的参数都会给出一个警告。这是一种我不想被唠叨的警告(至少，曾经是)。有一套与现实不符的警告并不能服务任何人。
通过确保构建总是干净的，每次遇到警告时，我就不必决策它是否无关紧要。忽略事情是一项脑力劳动，我要摆脱所有不相关的脑力劳动。有一个干净的构建也可以让他人更容易接手我的工作。如果我留下警告，其他人将不得不面对这些相关或不相关的错误。或者干脆忽略掉所有金高，包括那些重要的内容。
构建中的警告很有用。你只是需要在它们刚开始出现时就摆脱它们。不要等到非得大扫除。当那些你不想看到的事物出现时，正确地清理它们。修复警告的源头，要么灭了这些警告，要么修改警告的策略。保持构建的干净不紧紧实保证没有编译错误和测试失败：警告也同样重要，是代码卫生的关键。
