在C和C ++中，哪些方法可以防止在需要等价（==）的情况下意外使用工作分配（=）？

在C和C ++中，编写带有严重错误的以下代码非常容易。

char responseChar = getchar();
int confirmExit = 'y' == tolower(responseChar);
if (confirmExit = 1)
{
    exit(0);
}

错误是if语句应该是：

if (confirmExit == 1)

按照编码，它将每次退出，因为confirmExit发生了变量分配，然后confirmExit将其用作表达式的结果。

是否有防止这种错误的好方法？

最好的技术是提高编译器的警告级别。然后，如果有条件，它将警告您有关潜在的分配。

确保使用零警告编译代码（无论如何应该这样做）。如果您想成为书呆子，则将编译器设置为将警告视为错误。

使用Yoda条件句（将常量放在左侧）是大约十年前流行的另一种技术。但是，它们使代码更难阅读（并且由于它们的阅读方式不自然（因此除非您是Yoda），因此得以维护），并且提供的好处没有增加警告级别（带来更多警告的额外好处）之外。

警告实际上是代码中的逻辑错误，应予以纠正。

您总是可以做一些根本的事情，例如测试软件。我什至不表示自动化的单元测试，只是每位有经验的开发人员都会通过两次运行他的新代码，一次确认退出而一次不退出来摆脱习惯。这就是大多数程序员认为它不是问题的原因。

防止在表达式中错误使用赋值的传统方法是将常量放在左侧，将变量放在右侧。

if (confirmExit = 1)  // Unsafe

if (1=confirmExit)    // Safe and detected at compile time.

编译器将报告非法分配错误，并将其报告给类似于以下内容的常量。

.\confirmExit\main.cpp:15: error: C2106: '=' : left operand must be l-value

修改后的条件为：

  if (1==confirmExit)    

如下面的注释所示，许多人认为这是不合适的方法。

我同意每个人所说的“编译器警告”，但我想添加另一种技术：代码审查。如果您有审查所有提交的代码的政策，最好在提交之前进行审查，那么在审查期间很可能会遇到这种情况。

首先，提高警告等级永远不会造成伤害。

如果您不希望条件语句在if语句本身中测试赋值的结果，那么多年来，与许多C和C ++程序员一起工作，并且从未听说过先比较常量if(1 == val)是一件坏事，那么您可以尝试这种构造。

如果您的项目负责人批准您这样做，则不必担心其他人的想法。真正的证明是您或其他人以后几个月或几年后都可以理解您的代码。

但是，如果您打算测试分配的结果，则使用更高的警告可能会（可能会）将分配捕获为常数。

像往常一样晚了，但是静态代码分析是关键

现在，大多数IDE都在对编译器进行语法检查之外提供SCA，并且可以使用其他工具，包括那些实现MISRA（*）和/或CERT-C准则的工具。

声明：我是MISRA C工作组的成员，但我以个人身份发布。我也独立于任何工具供应商

仅使用左手分配，编译器警告会有所帮助，但您必须确保获得正确的级别，否则您将被无意义的警告所淹没，或者不会被告知想要看到的警告。