编译警告 —— 软件质量的第一道关

关于编译警告，我身边所有的工程师都近乎没有怎么关注过。对于他们，对于软件而言，重要的是编译通过，而那些警告，并不是他们所在乎的。在我刚刚入职的前几年，我也曾秉承着这样的错误理念。不过，没有出现问题不代表是正确的，有时候可能仅仅是因为你的运气好，然而你的同事有时候就没那么好运了。在软件交付节点前，莫名其妙的软件崩溃真的会把人逼疯。

当然，我也理解，当你写完刚刚出炉的新鲜代码时，你心中的一块表也开始动了！不想编译，不想测试，一股脑儿地就想把代码上线发布掉！“最多编译两遍就能通过！”是你的口头禅！第一遍：让编译器检查所有接口和语法错误第二遍：修改编译错误并完美编译通过“只要再编译一次就OK了” —— 这是一种对待代码的草率心态！在长远上反而要花掉更多时间！一顿花式 “Debug” 下来，还不如老手的一句“先看看编译 Warning ”要来的靠谱！也许这时候你才能体会到代码评审表上的关注 “Warning” 是多么的重要！在软件中有很大一部分的低端错误都是来源于形参类型错误以及隐式类型转换。这类型的错误只有在某些特定工况下才会发生，在测试过程中往往被疏忽，然而一旦出现问题，软件一般就直接崩溃了，事后调查起来也十分费劲。我们知道随着软件开发的深入，越晚后期的 bug 修复的代价就越高。好在编译器在软件开发的最最早期就能识别到这些错误，可以说是性价比最高的检查工具。

很多新手工程师放着编译器这么好的检查不用，而去迷信其他花里胡哨的“黑操作“，着实是本末倒置。那我们在平常软件开发中，有没有一些简单行之有效的方法能让我们来避免这些低级错误呢？我在这里帮大家总结的以下四条：良好的代码风格将编译警告打开（甚至调成最高级别）使用第三方工具来帮助检查（如QAC等）消除所有编译警告（无法消除的，要给出解释）后面找机会和大家来细细探讨一下吧，希望大家都能编出没有 error ，没有warning 的