别着急:你不必这么做，也没有必要。-Wall和-Werror是由代码重构狂人为自己设计的:它是由编译器开发人员发明的，目的是避免在用户端编译器或编程语言更新后破坏现有的构建。特性本身并不是什么，而是关于是否破坏构建的决定。

使用与否完全取决于您的喜好。我一直在用它，因为它能帮我改正错误。

别着急:你不必这么做，也没有必要。-Wall和-Werror是由代码重构狂人为自己设计的:它是由编译器开发人员发明的，目的是避免在用户端编译器或编程语言更新后破坏现有的构建。特性本身并不是什么，而是关于是否破坏构建的决定。

使用与否完全取决于您的喜好。我一直在用它，因为它能帮我改正错误。

将警告视为错误只是自律的一种方式:您正在编译一个程序来测试那个闪亮的新功能，但是在您修复那些草率的部分之前，您无法测试。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就没有意义了。将警告作为警告将允许您做出明智的决定，是否仍然有意义运行您即将开始的调试会话，还是中止它并首先修复警告。

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

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

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

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

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

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

这种做法对我们很有效。

作为使用遗留嵌入式C代码的人，启用编译器警告有助于在提出修复时显示许多弱点和需要调查的领域。在GCC中，使用-Wall和-Wextra甚至-Wshadow变得至关重要。我不打算一一列举每一个危险，但我将列出一些已经出现的有助于显示代码问题的危险。

变量被落下

这可以很容易地指出未完成的工作和可能没有使用所有传递变量的区域，这可能是一个问题。让我们来看看一个简单的函数，它可能会触发这个:

int foo(int a, int b)
{
   int c = 0;

   if (a > 0)
   {
        return a;
   }
   return 0;
}

在没有-Wall或-Wextra的情况下编译它不会返回任何问题。-Wall会告诉你c从来不用:

foo.c:在函数' foo '中:

Foo.c:9:20:警告:未使用的变量' c ' (-Wunused-variable)

wextra还会告诉你参数b什么都不做:

foo.c:在函数' foo '中:

Foo.c:9:20:警告:未使用的变量' c ' (-Wunused-variable)

foo.c:7:20:警告:未使用参数' b ' [-Wunused-parameter] int foo(int a, int b)

全局变量阴影

这一点有点难，直到使用-Wshadow才显示出来。让我们修改上面的示例，只添加一个，但是刚好有一个全局变量和一个局部变量同名，这在尝试使用两者时造成了很多混乱。

int c = 7;

int foo(int a, int b)
{
   int c = a + b;
   return c;
}

当打开-Wshadow时，很容易发现这个问题。

Foo.c:11:9:警告:声明' c '隐藏全局声明 (-Wshadow) Foo.c:1:5:注意:阴影声明在这里

格式字符串

这在GCC中不需要任何额外的标志，但在过去它仍然是问题的根源。一个简单的函数试图打印数据，但有格式化错误，可能是这样的:

void foo(const char * str)
{
    printf("str = %d\n", str);
}

这不会打印字符串，因为格式化标志是错误的，GCC会很高兴地告诉你这可能不是你想要的:

foo.c:在函数' foo '中:

Foo.c:10:12:警告:格式' %d '期望 参数类型为' int '，但参数2的类型为' const char * ' (-Wformat =)

这只是编译器可以为您进行双重检查的许多事情中的三件。还有很多其他的方法，比如使用未初始化的变量。

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

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

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