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

下面是一个例子:

A类行为如下:

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

B类做以下事情

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

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

考虑以下问题:

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

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

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

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

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

如果不使用{和}，很容易意外地用注释更改控制流。例如:

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

如果你用一行注释注释掉do_something_else()，你会得到这样的结果:

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

它会编译，但must_always_do_this()并不总是被调用。

我们在代码库中遇到了这个问题，有人在发布之前很快地禁用了一些功能。幸运的是，我们在代码审查中发现了它。

让我们尝试在增加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相关联。

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

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

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

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

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

我正在处理的代码库被那些病态地厌恶大括号的人分散在代码中，对于后来的人来说，它确实可以对可维护性产生影响。

我遇到的最常见的问题是:

if (really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

所以当我出现并希望添加一个then语句时，如果我不小心，我很容易以这样的方式结束:

if (really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

考虑到添加大括号需要1秒左右的时间，并且可以为您节省至少几分钟的调试时间，为什么不选择减少歧义性呢?在我看来这是虚假的节约。

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

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++;
}

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

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;