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

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

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

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

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

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

你应该总是启用编译器警告，因为编译器经常会告诉你代码哪里出了问题。为此，您将-Wall -Wextra传递给编译器。

您通常应该将警告视为错误，因为警告通常表示您的代码有问题。然而，通常很容易忽略这些错误。因此，将它们视为错误将导致构建失败，因此您不能忽略这些错误。若要将警告视为错误，请将-Werror传递给编译器。

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

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

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

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

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

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

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

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

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

这种做法对我们很有效。

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