将警告视为错误只是自律的一种方式:您正在编译一个程序来测试那个闪亮的新功能，但是在您修复那些草率的部分之前，您无法测试。werror提供了其他信息。它只是非常明确地设定了优先级:

在修复现有代码中的问题之前，不要添加新代码

重要的是心态，而不是工具。编译器诊断输出是一种工具。MISRA C(嵌入式C)是另一个工具。使用哪一种并不重要，但可以说编译器警告是最简单的工具(只需设置一个标志)，而且信噪比非常高。所以没有理由不使用它。

No tool is infallible. If you write const float pi = 3.14;, most tools won't tell you that you defined π with a bad precision which may lead to problems down the road. Most tools won't raise an eyebrow on if(tmp < 42), even if it's commonly known that giving variables meaningless names and using magic numbers is a way to disaster in big projects. You have to understand that any "quick test" code you write is just that: a test, and you have to get it right before you move on to other tasks, while you still see its shortcomings. If you leave that code as is, debugging it after you spend two months adding new features will be significantly harder.

一旦你进入了正确的心态，使用-Werror就没有意义了。将警告作为警告将允许您做出明智的决定，是否仍然有意义运行您即将开始的调试会话，还是中止它并首先修复警告。

处理警告不仅能写出更好的代码，还能让你成为更好的程序员。警告会告诉你一些今天对你来说微不足道的事情，但总有一天坏习惯会回来咬你的头。

使用正确的类型，返回该值，计算该返回值。花点时间思考“在这种情况下，这真的是正确的类型吗?”“我需要把这个还回去吗?”最重要的是;“这个代码在未来10年里还能移植吗?”

首先要养成编写无警告代码的习惯。

警告是等待发生的错误。 因此，您必须启用编译器警告，并整理代码以删除任何警告。

将警告视为错误只有一个问题:当你使用来自其他来源的代码时(例如，微软库，开源项目)，他们没有正确地完成他们的工作，编译他们的代码会产生大量的警告。

在编写代码时，我总是确保它不会产生任何警告或错误，并在编译之前进行清理，而不会产生任何无关的噪音。我不得不处理的垃圾让我感到震惊，当我不得不构建一个大项目时，看着一串警告从编译器应该只声明它处理了哪些文件的地方经过时，我感到震惊。

我也记录我的代码，因为我知道软件真正的生命周期成本主要来自维护，而不是最初的编写，但这是另一回事……

我曾经在一家制造电子测试设备的大公司(财富50强)工作过。

我的团队的核心产品是一个MFC程序，多年来，它产生了数百个警告。在几乎所有的案例中都被忽略了。

当出现bug时，这简直是一场噩梦。

在那个职位之后，我很幸运地被一家新创业公司聘为第一个开发人员。

我鼓励所有构建都采用“无警告”策略，并将编译器警告级别设置为相当吵闹的级别。

我们的做法是使用#pragma warning - push/disable/pop用于开发人员确定确实没问题的代码，并在调试级别使用日志语句，以防万一。

这种做法对我们很有效。

为什么要启用警告?

众所周知，C和c++编译器在默认情况下不擅长报告一些常见的程序员错误，例如:

忘记初始化变量 忘记从函数返回值 printf和scanf族中的参数与格式字符串不匹配 函数的使用没有事先声明(仅限C语言)

这些可以被检测和报告，只是通常不是默认情况;此特性必须通过编译器选项显式地请求。

如何启用警告?

这取决于你的编译器。

微软C和c++编译器理解/W1、/W2、/W3、/W4和/Wall这样的开关。至少使用/W3。/W4和/Wall可能会对系统头文件发出错误的警告，但如果您的项目使用这些选项之一进行了干净的编译，那么就使用它。这些选择是相互排斥的。

大多数其他编译器都理解-Wall、-Wpedantic和-Wextra这样的选项。-Wall是必要的，其余的都是推荐的(注意，尽管它的名字，-Wall只启用最重要的警告，而不是全部)。这些选项可以单独使用，也可以一起使用。

您的IDE可能有办法从用户界面启用这些功能。

为什么我要把警告当作错误?它们只是警告!

A compiler warning signals a potentially serious problem in your code. The problems listed above are almost always fatal; others may or may not be, but you want compilation to fail even if it turns out to be a false alarm. Investigate each warning, find the root cause, and fix it. In the case of a false alarm, work around it — that is, use a different language feature or construct so that the warning is no longer triggered. If this proves to be very hard, disable that particular warning on a case by case basis.

你不希望只是把警告作为警告，即使它们都是假警报。对于发出的警告总数小于7的非常小的项目来说，这是可行的。再多一点，新的警告就很容易淹没在大量熟悉的旧警告中。不要允许这种情况发生。只是让你所有的项目编译干净。

Note this applies to program development. If you are releasing your project to the world in the source form, then it might be a good idea not to supply -Werror or equivalent in your released build script. People might try to build your project with a different version of the compiler, or with a different compiler altogether, which may have a different set of warnings enabled. You may want their build to succeed. It is still a good idea to keep the warnings enabled, so that people who see warning messages could send you bug reports or patches.

如何将警告视为错误?

这同样是通过编译器开关完成的。/WX是微软的，大多数其他人使用-Werror。在这两种情况下，如果产生任何警告，编译都会失败。

这就够了吗?

可能不是!随着优化级别的提高，编译器开始越来越仔细地检查代码，而这种仔细检查可能会发现更多的错误。因此，不要满足于警告开关本身，总是使用它们时，编译优化启用(-O2或-O3，或/O2如果使用MSVC)。