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

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

因此，从使用的其他样式指南和工具中单独查看单个样式规则可能是徒劳的。我将介绍关于规则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).

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

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

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

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

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

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

if(guardClause)
      throw new SomeException(..)

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

e.g.

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

应该被重构为

if(someCondition)
    doFunctionalThingA();

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

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

我的2 c:

使用缩进

很明显

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

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

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

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

Const对象在比较的左边

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

对于>= 0的变量使用unsigned

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

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

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

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

下面是一个例子:

A类行为如下:

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

B类做以下事情

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

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

考虑以下问题:

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

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

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

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

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