你一定要启用编译器警告，因为一些编译器不擅长报告一些常见的编程错误，包括以下:

初始化变量会被遗忘 从一个被错过的函数返回一个值 printf和scanf族中的简单参数与格式字符串不匹配 函数的使用没有事先声明，尽管这只在C中发生

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

一些警告可能意味着代码中可能出现语义错误或可能出现UB。例如;if()之后，一个未使用的变量，一个被局部变量掩盖的全局变量，或者有符号和无符号的比较。许多警告与编译器中的静态代码分析器或在编译时检测到的违反ISO标准有关，这“需要诊断”。虽然在特定情况下，这些事件可能是合法的，但大多数情况下，它们是设计问题的结果。

一些编译器，例如GCC，有一个命令行选项来激活“警告为错误”模式。这是一个很好的工具，如果残酷，教育新手。

众所周知，就hll而言，C是一种相当低级的语言。虽然c++看起来是一种比C高级得多的语言，但它仍然具有C的一些特征。其中一个特点就是这些语言是由程序员设计的，为程序员设计的——特别是那些知道自己在做什么的程序员。

(对于这个答案的其余部分，我将专注于C。我要说的大部分内容也适用于c++，尽管可能没有那么强烈。尽管Bjarne Stroustrup有一句名言:“C很容易搬起石头砸自己的脚;c++让它变得更难，但当你这样做的时候，它会把你的整条腿都炸掉。”)

如果你知道你在做什么——真的知道你在做什么——有时候你可能不得不“打破规则”。但大多数时候，我们大多数人都会同意，善意的规则让我们所有人都远离麻烦，一直肆意违反这些规则是一个坏主意。

But in C and C++, there are surprisingly large numbers of things you can do that are "bad ideas", but which aren't formally "against the rules". Sometimes they're a bad idea some of the time (but might be defensible other times); sometimes they're a bad idea virtually all of the time. But the tradition has always been not to warn about these things — because, again, the assumption is that programmers know what they are doing, they wouldn't be doing these things without a good reason, and they'd be annoyed by a bunch of unnecessary warnings.

当然，并不是所有的程序员都知道自己在做什么。特别是，每个C程序员(无论多么有经验)都要经历一个开始C程序员的阶段。即使是有经验的C程序员也会粗心大意，犯错误。

最后，经验表明，程序员不仅会犯错误，而且这些错误会产生真正的、严重的后果。如果你犯了一个错误，编译器没有警告你，而且程序没有立即崩溃，或者因为它而做一些明显的错误，这个错误可能潜伏在那里，隐藏，有时长达数年，直到它造成一个真正的大问题。

So it turns out that, most of the time, warnings are a good idea, after all. Even the experienced programmers have learned that (actually, it's "especially the experienced programmers have learned that"), on balance, the warnings tend to do more good than harm. For every time you did something wrong deliberately and the warning was a nuisance, there are probably at least ten times you did something wrong by accident and the warning saved you from further trouble. And most warnings can be disabled or worked around for those few times when you really want to do the "wrong" thing.

(这类“错误”的一个经典例子是if(A = b)的测试。大多数时候，这确实是一个错误，所以现在大多数编译器都会对此发出警告——有些甚至是默认的。但是如果你真的想把b赋值给a并测试结果，你可以通过输入if((a = b))来禁用警告。

The second question is, why would you want to ask the compiler to treat warnings as errors? I'd say it's because of human nature, specifically, the all-too-easy reaction of saying "Oh, that's just a warning, that's not so important, I'll clean that up later." But if you're a procrastinator (and I don't know about you, but I'm a world-class procrastinator) it's easy to put off the necessary cleanup for basically ever — and if you get into the habit of ignoring warnings, it gets easier and easier to miss an important warning message that's sitting there, unnoticed, in the midst of all the ones you're relentlessly ignoring.

因此，要求编译器将警告视为错误是你可以对自己玩的一个小技巧，以避免这个人类的弱点，迫使自己立即修复警告，否则你的程序将无法编译。

Personally, I'm not as insistent about treating warnings as errors — in fact, if I'm honest, I can say that I don't tend to enable that option in my "personal" programming. But you can be sure I've got that option enabled at work, where our style guide (which I wrote) mandates its use. And I would say — I suspect most professional programmers would say — that any shop that doesn't treat warnings as errors in C is behaving irresponsibly, is not adhering to commonly-accepted industry best practices.

非固定的警告迟早会导致代码中的错误。

例如，调试分段错误需要程序员追踪错误的根源(原因)，它通常位于代码中比最终导致分段错误的行更前面的位置。

很典型的情况是，导致错误的行是编译器发出警告而你忽略的行，而导致分段错误的行是最终抛出错误的行。

修复警告就等于修复了问题……一个经典的!

以上的演示…考虑下面的代码:

#include <stdio.h>

int main(void) {
  char* str = "Hello, World!!";
  int idx;

  // Colossal amount of code here, irrelevant to 'idx'

  printf("%c\n", str[idx]);

  return 0;
}

当使用传递给GCC的"Wextra"标志进行编译时，给出:

main.c: In function 'main':
main.c:9:21: warning: 'idx' is used uninitialized in this function [-Wuninitialized]
    9 |   printf("%c\n", str[idx]);
      |                     ^

我可以忽略它，然后执行代码……然后我就会看到一个“重大”分割错误，就像我的IP伊壁鸠鲁教授曾经说过的那样:

段错误

为了在现实场景中调试这一点，人们将从导致分段错误的行开始，并试图跟踪原因的根源是什么……他们将不得不在那里的大量代码中搜索i和str发生了什么……

直到有一天，他们发现idx使用时没有初始化，因此它有一个垃圾值，这导致索引字符串(方式)超出其界限，从而导致分割错误。

如果他们没有忽视这个警告，他们就会立即发现这个漏洞!

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

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

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

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

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