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

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

因此，从使用的其他样式指南和工具中单独查看单个样式规则可能是徒劳的。我将介绍关于规则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被违反时，制作一个立即抱怨(甚至修复)的工具并不难，因此可以及时发现大多数错误。

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

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

它通过清楚地定义循环和条件块的范围，使您的代码更具可读性。它还可以避免你意外出错。

我能想到的最贴切的例子是:

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

Which if will the else be paired with? Indentation implies that the outer if gets the else, but that's not actually how the compiler will see it; the inner if will get the else, and the outer if doesn't. You would have to know that (or see it behave that way in debugging mode) to figure out by inspection why this code might be failing your expectations. It gets more confusing if you know Python; in that case you know that indentation defines code blocks, so you would expect it to evaluate according to the indentation. C#, however, doesn't give a flying flip about whitespace.

话虽如此，从表面上看，我并不特别同意这个“总是使用括号”的规则。它使代码的垂直噪声非常大，降低了快速读取代码的能力。如果语句是:

if(someCondition)
   DoSomething();

... then it should be written just like this. The statement "always use brackets" sounds like "always surround mathematical operations with parentheses". That would turn the very simple statement a * b + c / d into ((a * b) + (c / d)), introducing the possibility of missing a close-paren (the bane of many a coder), and for what? The order of operations is well-known and well-enforced, so the parentheses are redundant. You'd only use parentheses to enforce a different order of operations than would normally be applied: a * (b+c) / d for instance. Block braces are similar; use them to define what you want to do in cases where it differs from the default, and is not "obvious" (subjective, but usually pretty common-sense).

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

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

我认为第一个比第二个更清楚。它给人一种结束指令的感觉。使用短代码是可以的，但是当代码变得复杂时，{…}帮助很大，即使它是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++;

有许多可能的方法来编写控制语句;它们的某些组合可能共存而不损害易读性，但其他组合将引起麻烦。的风格

if (condition)
  statement;

可以与其他一些编写控制语句的方法很好地共存，但与其他方法就不那么好了。如果多行受控语句被写成:

if (condition)
{
  statement;
  statement;
}

那么，从视觉上看，哪些if语句控制单行，哪些语句控制多行就很明显了。然而，多行If语句被写成:

if (condition) {
  statement;
  statement;
}

那么，如果构造不添加必要的大括号，那么试图扩展单个语句的可能性就会高得多。

如果代码库大量使用这种形式，那么下一行的单个语句if语句也可能有问题

if (condition) statement;

我个人的偏好是将语句放在自己的行上通常可以提高易读性，除非有许多if语句具有类似的控制块，例如。

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

在这种情况下，我通常会在这些if语句的前面和后面加上一个空行，以便在视觉上将它们与其他代码分开。在相同的缩进处使用一系列以if开头的语句将提供一个清晰的视觉指示，表明有不寻常的地方。