所有其他答案都捍卫了讲师的规则3。

让我说我同意你的观点:这个规则是多余的，我不建议它。确实，如果你总是添加花括号，理论上可以防止错误。另一方面，我在现实生活中从未遇到过这个问题:与其他答案所暗示的相反，我从未忘记在必要时添加花括号。如果使用适当的缩进，一旦多个语句缩进，就需要立即添加花括号。

Component 10给出的答案实际上突出了唯一可能导致错误的情况。但另一方面，通过正则表达式替换代码总是需要非常小心。

现在让我们看看奖章的另一面:总是使用花括号有缺点吗?其他答案完全忽略了这一点。但也有一个缺点:它占用了大量的垂直屏幕空间，这反过来又会使您的代码不可读，因为这意味着您不得不超出必要的滚动次数。

考虑一个函数在开头有很多保护子句(是的，下面是糟糕的c++代码，但在其他语言中，这将是相当常见的情况):

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

这是可怕的代码，我强烈认为下面的代码可读性更强:

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

类似地，短嵌套循环可以从省略花括号中获益:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

比较:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

第一个代码很简洁;第二个代码很臃肿。

是的，这可以通过在前一行上加上开大括号在一定程度上得到缓解。所以:如果你坚持使用大括号，至少要把左大括号放在前一行。

简而言之:不要编写占用屏幕空间的不必要代码。

在最初写答案的时间里，我基本上接受了流行的代码风格，使用大括号，除非我能把整个语句放在前一行。我仍然认为不使用冗余大括号通常更具可读性，而且我仍然从未遇到过由此引起的错误。

我的2 c:

使用缩进

很明显

永远不要依赖运算符优先级——总是使用括号

我不会使用“从不”和“总是”这样的词，但总的来说，我认为这条规则是有用的。在某些语言(Lisp, Smalltalk)中，这不是问题。

总是使用{}块-即使是单行

我从来没有这样做过，也从来没有遇到过任何问题，但我可以看到它对学生有什么好处，特别是如果他们以前学过Python的话。

Const对象在比较的左边

尤达条件?不,请。它损害了可读性。在编译代码时使用最大警告级别即可。

对于>= 0的变量使用unsigned

好的。有趣的是，我听到斯特劳斯特鲁普不同意。

删除后将指针设置为NULL -双重删除保护

坏的建议!永远不要使用指向已删除或不存在的对象的指针。

所有其他答案都捍卫了讲师的规则3。

让我说我同意你的观点:这个规则是多余的，我不建议它。确实，如果你总是添加花括号，理论上可以防止错误。另一方面，我在现实生活中从未遇到过这个问题:与其他答案所暗示的相反，我从未忘记在必要时添加花括号。如果使用适当的缩进，一旦多个语句缩进，就需要立即添加花括号。

Component 10给出的答案实际上突出了唯一可能导致错误的情况。但另一方面，通过正则表达式替换代码总是需要非常小心。

现在让我们看看奖章的另一面:总是使用花括号有缺点吗?其他答案完全忽略了这一点。但也有一个缺点:它占用了大量的垂直屏幕空间，这反过来又会使您的代码不可读，因为这意味着您不得不超出必要的滚动次数。

考虑一个函数在开头有很多保护子句(是的，下面是糟糕的c++代码，但在其他语言中，这将是相当常见的情况):

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

这是可怕的代码，我强烈认为下面的代码可读性更强:

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

类似地，短嵌套循环可以从省略花括号中获益:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

比较:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

第一个代码很简洁;第二个代码很臃肿。

是的，这可以通过在前一行上加上开大括号在一定程度上得到缓解。所以:如果你坚持使用大括号，至少要把左大括号放在前一行。

简而言之:不要编写占用屏幕空间的不必要代码。

在最初写答案的时间里，我基本上接受了流行的代码风格，使用大括号，除非我能把整个语句放在前一行。我仍然认为不使用冗余大括号通常更具可读性，而且我仍然从未遇到过由此引起的错误。

在“总是使用牙套”的营地呆了10年之后，我最近开始不怎么使用牙套了。 主要是受到Bob叔叔关于如何编写干净代码的争论的启发，我现在相信不使用大括号编写代码更具有可读性。

if(guardClause)
      throw new SomeException(..)

Bob大叔认为，在if/for语句中编写多行代码是潜在的可读性问题。

e.g.

if(someCondition)
{
   doTechnicalThingX();
   doTechnicalThingY();
   doTechnicalThingZ();
}

应该被重构为

if(someCondition)
    doFunctionalThingA();

对我来说，不把大括号放在那里是有帮助的，因为我得到提醒，我在if块中写了太多代码。

正如其他人所提到的，我相信代码风格是团队决策。

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

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;

我必须承认，我并不总是在单行中使用{}，但这是一种很好的练习。

假设你写的代码没有括号，看起来像这样: For (int I = 0;I < 100;+ + i) For (int j = 0;J < 100;+ + j) DoSingleStuff ();

过了一段时间，你想在j循环中添加一些其他东西，你只是通过对齐来做，忘记添加括号。

Memory deallocation is faster. Let’s say you have a big scope and create big arrays inside (without new so they are on the stack). Those arrays are removed from memory just after you leave the scope. But it is possible that you use that array in one place and it will be on the stack for a while and be some kind of rubbish. As a stack have limited and quite small size, it is possible to exceed the stack size. So in some cases it is better to write {} to preventing that. Note that this is not for a single line, but for such situations: if (...) { //SomeStuff... {//we have no if, while, etc. //SomeOtherStuff } //SomeMoreStuff } The third way to use is similar to the second. It is just not to make the stack cleaner, but to open some functions. If you use mutex in long functions usually it is better to lock and unlock just before accessing data and just after finishing reading/writing that. Note: This way is used if you have some of your own class or struct with a constructor and destructor to lock memory. What is more: if (...) if (...) SomeStuff(); else SomeOtherStuff(); // Goes to the second if, but alignment shows it is on first...

总而言之，我不能说，总是使用{}的最佳方式是单行，但这样做并没有什么不好。

如果你编写的是编译代码，但是如果你的代码是被解释的，那么你的代码就会非常非常慢。非常轻微。