作为使用遗留嵌入式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 =)

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

其他的回答都很好，我不想重复他们说过的话。

One other aspect to "why enable warnings" that hasn't properly been touched on is that they help enormously with code maintenance. When you write a program of significant size, it becomes impossible to keep the whole thing in your head at once. You typically have a function or three that you're actively writing and thinking about, and perhaps a file or three on your screen that you can refer to, but the bulk of the program exists in the background somewhere and you have to trust that it keeps working.

如果你改变的某些东西给你看不见的东西带来了麻烦，你就会提醒自己。

例如Clang警告-Wswitch-enum。如果您在枚举上使用开关而漏掉了一个可能的枚举值，则会触发警告。您可能认为这是一个不太可能犯的错误:在编写switch语句时，您可能至少查看了枚举值列表。您甚至可能有一个IDE为您生成开关选项，不为人为错误留下任何空间。

六个月后，当您向枚举中添加另一个可能的条目时，这个警告才真正发挥作用。同样，如果您正在考虑所讨论的代码，那么您可能不会有问题。但是如果这个枚举用于多个不同的目的，并且它是用于您需要额外选项的其中一个目的，那么很容易忘记更新您六个月没有接触过的文件中的开关。

You can think of warnings in the same way as you'd think of automated test cases: they help you make sure that the code is sensible and doing what you need when you first write it, but they help even more to make sure that it keeps doing what you need while you prod at it. The difference is that test cases work very narrowly to the requirements of your code and you have to write them, while warnings work broadly to sensible standards for almost all code, and they're very generously supplied by the boffins who make the compilers.

c++编译器接受明显导致未定义行为的编译代码，这是编译器的一个主要缺陷。他们不修复这个问题的原因是，这样做可能会破坏一些可用的构建。

大多数警告应该是阻止构建完成的致命错误。默认情况下只显示错误并进行构建是错误的，如果您不覆盖它们，将警告视为错误，并留下一些警告，那么您可能会导致程序崩溃并做一些随机的事情。

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

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

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

编译器警告是你的朋友

我在传统的Fortran 77系统上工作。编译器告诉我有价值的东西:在子例程调用上的参数数据类型不匹配，如果我有一个变量或子例程参数没有被使用，那么在值被设置到变量之前使用一个局部变量。这些几乎都是错误。

当我的代码编译干净，97%的工作。与我一起工作的另一个人在编译时关闭了所有警告，在调试器中花费数小时或数天，然后让我帮忙。我只是用警告编译他的代码，然后告诉他要修改什么。

由于某些原因，c++中的编译器警告非常有用。

它可以告诉你，你可能在哪里犯了一个错误，这可能会影响你的操作的最终结果。例如，如果你没有初始化一个变量，或者如果你使用“=”而不是“==”(这只是例子) 它还允许向你展示你的代码不符合c++标准的地方。这很有用，因为如果代码符合实际标准，那么将很容易将代码移到其他平台。

一般来说，警告是非常有用的，可以告诉您代码中哪里有错误，这些错误可能会影响算法的结果，或者在用户使用您的程序时防止出现某些错误。