因为当你有两个没有{}的语句时，很容易漏掉一个问题。让我们假设代码是这样的。

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

看起来不错。它的问题很容易被忽略，特别是当包含代码的函数非常大的时候。问题是，失败是无条件的。您可以很容易地想象这是多么令人沮丧(让您问为什么上次hash_update总是失败，毕竟在hash_update函数中一切看起来都很好)。

然而，这并不意味着我支持在所有地方都添加{}(在我看来，到处都看到{}很烦人)。虽然这可能会导致问题，但在我自己的项目中却从来没有，因为我个人的编码风格禁止没有{}的条件，当它们不在同一行时(是的，我同意我的编码风格是非常规的，但我喜欢它，并且我在为其他项目贡献时使用项目的代码风格)。这使得下面的代码很好。

if (something) goto fail;

但下一个不是。

if (something)
    goto fail;

让我们尝试在增加j时也修改i:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

噢,不!来自Python，这看起来不错，但实际上不是，因为它相当于:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

当然，这是一个愚蠢的错误，但即使是有经验的程序员也会犯这个错误。

在ta.speot中指出了另一个很好的理由。的回答。

我能想到的第三个是嵌套的if:

if (cond1)
   if (cond2) 
      doSomething();

现在，假设您现在想在未满足cond1时执行somethingelse()(新特性)。所以:

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

这显然是错误的，因为else与内部的if相关联。

编辑:既然这引起了一些关注，我将澄清我的观点。我想回答的问题是

使用第一个版本的好处是什么?

我已经描述过了。有一些好处。但是，在我看来，“总是”的规则并不总是适用。所以我并不完全支持

总是使用{}块-即使是单行//不可以，为什么??

我并不是说总是使用{}块。如果这是一个足够简单的条件和行为，那就不要。如果你怀疑有人可能稍后会来修改你的代码来增加功能，那就这么做。

我对这位讲师的能力表示怀疑。考虑到他 点:

OK Would anyone really write (or want to read) (b*b) - ((4*a)*c)? Some precedences are obvious (or should be), and the extra parentheses just add to confusion. (On the other hand, you _should_ use the parentheses in less obvious cases, even if you know that they're not needed.) Sort of. There are two wide spread conventions for formatting conditionals and loops: if ( cond ) { code; } and: if ( cond ) { code; } In the first, I'd agree with him. The opening { is not that visible, so it's best to assume it's always there. In the second, however, I (and most of the people I've worked with) have no problem with omitting the braces for a single statement. (Provided, of course, that the indentation is systematic and that you use this style consistently. (And a lot of very good programmers, writing very readable code, omit the braces even when formatting the first way.) NO. Things like if ( NULL == ptr ) are ugly enough to hinder readability. Write the comparisons intuitively. (Which in many cases results in the constant on the right.) His 4 is bad advice; anything which makes the code unnatural makes it less readable. NO. Anything but int is reserved for special cases. To experienced C and C++ programmers, the use of unsigned signals bit operators. C++ doesn't have a real cardinal type (or any other effective subrange type); unsigned doesn't work for numeric values, because of the promotion rules. Numerical values on which no arithmetic operations would make sense, like serial numbers, could presumably be unsigned. I'd argue against it, however, because it sends the wrong message: bitwise operations don't make sense either. The basic rule is that integral types are int, _unless_ there is a significant reason for using another type. NO. Doing this systematically is misleading, and doesn't actually protect against anything. In strict OO code, delete this; is often the most frequent case (and you can't set this to NULL), and otherwise, most delete are in destructors, so you can't access the pointer later anyway. And setting it to NULL doesn't do anything about any other pointers floating around. Setting the pointer systematically to NULL gives a false sense of security, and doesn't really buy you anything.

查看任何典型参考文献中的代码。Stroustrup违反 除了第一条，你给出的每一条规则。

我建议你换个讲师。一个真正知道什么的人 他说的是。

当你完成它时，最好将指针设置为NULL。

下面是一个例子:

A类行为如下:

分配一块内存 然后一段时间后，它删除这块内存，但不将指针设置为NULL

B类做以下事情

分配内存(在这个实例中，它得到的内存块恰好与类a删除的内存块相同)

在这一点上，类A和类B都有指向同一个内存块的指针，就类A而言，这块内存块不存在，因为它已经用完了。

考虑以下问题:

如果在类a中有一个逻辑错误，导致它写入现在属于类B的内存呢?

在这个特定的实例中，您不会得到一个糟糕的访问异常错误，因为内存地址是合法的，而类A现在有效地破坏了类B数据。

类B可能最终崩溃，如果它遇到意外值，当它崩溃时，很有可能，当问题出现在类a时，您将花费相当长的时间在类B中查找这个bug。

如果您已经将删除的内存指针设置为NULL，那么只要类A中的任何逻辑错误试图写入NULL指针，您就会得到一个异常错误。

如果您担心在指针第二次为NULL时使用双重删除会出现逻辑错误，那么可以为此添加assert。

我喜欢卢钦公认的答案。事实上，我经过艰苦的学习才知道他是对的，所以我总是使用大括号，即使是单行块。然而，就我个人而言，我在编写过滤器时做了一个例外，就像您在示例中所做的那样。这样的:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

在我看来很混乱。它将'for'循环和'if'语句分离为单独的操作，而实际上你的目的是一个操作:计算所有能被2整除的整数。在更有表现力的语言中，可以这样写:

j = [1..100].filter(_%2 == 0).Count

在缺少闭包的语言中，过滤器不能用单个语句表示，而必须是一个for循环，后面跟着一个if语句。然而，这仍然是程序员心中的一个动作，我相信这应该反映在代码中，如下所示:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}

它更直观，更容易理解。它使意图明确。

它还确保当新用户在添加新代码语句时不知不觉地漏掉{，}时，代码不会中断。