为了补充之前回答中非常明智的建议，我在重构一些代码时遇到的一个例子是:我正在修改一个非常大的代码库，从一个API切换到另一个API。第一个API调用设置Company Id，如下:

setCompIds( const std::string& compId, const std::string& compSubId );

而替换需要两次调用:

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

我开始使用正则表达式来改变这种情况，这非常成功。我们还通过样式传递代码，这确实使它更易于阅读。然后，在审查过程中，我发现在某些条件下，它正在改变:

if ( condition )
   setCompIds( compId, compSubId );

:

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

这显然不是我们所需要的。我不得不回到一开始，再次将替换处理为完全在一个块内，然后手动修改任何最终看起来愚蠢的东西(至少它不会是不正确的)。

我注意到style现在有了一个选项——add-括号，它允许你在没有括号的地方添加括号，如果你发现自己处于和我一样的位置，我强烈建议你这样做。

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

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

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

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

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

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

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

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

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

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

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

在“总是使用牙套”的营地呆了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;

纵观答案，没有人明确地说明了我习惯的那种实践，讲述你的代码的故事:

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

就变成:

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

将j++放在与if should相同的行上，向其他任何人发出信号:“我只想让这个块永远增加j”。当然，只有在行代码尽可能简单的情况下，这样做才有意义，因为在这里设置断点，正如前面提到的，并不是很有用。

事实上，我刚刚遇到了Twitter Storm API的一部分，它在Java中有这种“类型”代码。以下是执行代码的相关片段，在本幻灯片的第43页:

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

for循环块中有两个东西，所以我不会内联那个代码。也就是说,从来没有:

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

这很糟糕，我甚至不知道它是否有效(如预期的那样);不要这样做。新行和大括号有助于区分独立但相关的代码段，就像散文中的逗号或分号一样。上面的块是一个很长的句子，里面有几个从句和一些其他的语句，从来没有中断或暂停来区分不同的部分。

如果你真的想要向其他人发送一个只有一行的任务，请使用三元操作符或?:form:

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

但这几乎是代码高尔夫，我认为这不是很好的实践(我不清楚是否应该将j++放在:的一侧)。注意，我以前没有在c++中运行过三元运算符，我不知道这是否有效，但它确实存在。

简而言之:

想象一下您的读者(即维护代码的人)如何解释您的故事(代码)。让他们尽可能清楚地知道。如果您知道新手程序员/学生正在维护这个，甚至可能留下尽可能多的{}，这样他们就不会感到困惑。