正确看待C++编译警告

  你告诉我你有单元测试，你有代码提交自动构建，还有你说的构建后自动集成测试。好的，项目在貌似平稳的运行。可我已经感觉到缺陷的修复越来越困难，代码不断的、不声不响的退化，燃尽图越来越平缓。问题很简单也显而易见：开发人员的投入产出比在不断下降。

  当我真正要着手重构现有代码时，吃惊的发现一个大问题。这个项目大致有60多个核心应用，却有上千个编译警告。这明显是对于C++的编译警告的态度问题。编译警告有用吗？就这么忽略吗？这个先要说清楚。

  不管是项目中的敏捷方法，还是个人开发使的测试驱动，我们都有一个共同的目标：尽早尽快的发现问题。越早、越快，成本就越低，代价就越小。细数起来，无论如何，编完代码的第一个工作就是编译，代码功能以及质量也同样的反应在编译输出上。从这个角度讲，编译的错误信息、警告信息对我们是非常有用的。问题就出来了，错误无法回避，可警告信息，出于各种原因（比如时间压力、人为忽略），就有可能被忽略了。而这样的影响，恰恰会把一些前期错误推迟到单元测试阶段。

  如果足够幸运的话，你可能在单元测试时发现了问题。事实却总不尽如此，更为严重的，潜在问题，在单元测试时，悄悄的漏掉了。是的，现实中，测试总不能够发现所有的问题。而这，可能是以后问题的炸弹，或许是颗哑弹，或许在程序员的脚下爆炸，或许在客户的面前爆炸。

  好吧，如果你认为我足够啰嗦，而你又看到这里的话，也许会问，如果不关心这些幕后的话，程序员如何认识编译警告的价值呢？简而言之，尊重编译器，从尊重编译器诚实可靠的警告信息开始。

  基于以上原因，我决定拿出一部分时间，细查项目中的警告信息，甚至不惜抬出-Werror参数，逐步修正项目中的问题，强制加入代码规范里。 随后，我会借助代码、用有代表性的警告详细分析问题、以及其可能带来的后果。