所有其他答案都捍卫了讲师的规则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;
}

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

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

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

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

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

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

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

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

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

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

我认为第一个比第二个更清楚。它给人一种结束指令的感觉。使用短代码是可以的，但是当代码变得复杂时，{…}帮助很大，即使它是endif或begin…end。

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


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

总是使用花括号是一个非常简单而可靠的规则。然而，当有很多大括号时，代码可能看起来不优雅。

如果规则允许省略花括号，那么应该有更详细的样式规则和更复杂的工具。否则，它可能很容易导致混乱和混乱(不优雅)的代码。

因此，从使用的其他样式指南和工具中单独查看单个样式规则可能是徒劳的。我将介绍关于规则3的一些其他答案中没有提到的重要细节。

第一个有趣的细节是，该规则的大多数支持者都同意在else情况下违反该规则。换句话说，他们不希望得到这样的代码:

// Pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

相反，如果他们看到了，他们甚至会建议这样写:

// Not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

从技术上讲，这违反了规则3，因为在else和if之间没有花括号，但大多数人认为它更明显，更容易阅读。当试图用不需要动脑筋的工具将规则自动应用到代码库时，规则的这种二元性就会显现出来。的确，为什么要争论呢?只需让一个工具自动应用样式。

第二个细节(也经常被该规则的支持者遗忘)是，可能发生的错觉错误绝不仅仅是因为违反了该规则#3。事实上，这些几乎总是涉及违反规则#1(没有人会争辩)。再一次从自动工具的角度来看，当规则1被违反时，制作一个立即抱怨(甚至修复)的工具并不难，因此可以及时发现大多数错误。

第三个细节(该规则的反对者经常忘记)是由一个分号表示的空语句的令人困惑的性质。大多数具有一定经验的开发人员迟早会被一个放错位置的分号或使用一个分号编写的空语句所迷惑。两个花括号比一个分号更容易识别。

因此，我的建议是，与其同意这些规则，不如同意自动格式化工具的配置，并使其成为构建过程的一部分。这些工具往往比这种争论的参与者更聪明。

所有其他答案都捍卫了讲师的规则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;
}

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

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

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

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

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

假设你写的代码没有括号，看起来像这样: 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...

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

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