我的2 c:

使用缩进

很明显

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

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

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

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

Const对象在比较的左边

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

对于>= 0的变量使用unsigned

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

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

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

wrt 6:它更安全，因为删除空指针是一个无操作。因此，如果您碰巧两次经过这条路径，您不会因为释放空闲内存或已分配给其他内存而导致内存损坏。

这是静态文件作用域对象和单例对象的主要问题，它们没有非常明确的生命周期，并且已知它们在被销毁后会被重新创建。

在大多数情况下，您可以通过使用auto_ptrs来避免这种需要

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

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).

另一个添加花括号的例子。

有一次我在搜索一个bug，发现了这样的代码:

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

如果你逐行阅读这个方法，你会注意到方法中有一个条件，如果不为真就返回。但实际上，它看起来像其他100个简单的事件处理程序，它们基于某些条件设置一些变量。有一天，Fast Coder进来了，在方法的末尾添加了额外的变量设置语句:

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionally;
}

因此，setanothervariable无条件地在SomeConditionIsMet()时执行，但速度快的家伙没有注意到它，因为所有的行几乎都是相似的大小，即使返回条件垂直缩进，它也不那么明显。

如果条件返回的格式如下:

if (!SomeConditionIsMet())
{
    return;
}

它是非常明显的，快速编码器一眼就能发现它。

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

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

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

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

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

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

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

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

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