我在读c++老师的课堂笔记，他是这样写的:
使用缩进// OK 永远不要依赖运算符优先级-总是使用括号// OK 总是使用{}块-即使是单行//不可以，为什么?? Const对象在比较的左边// OK 对>= 0的变量使用unsigned，这是个不错的技巧 删除后将指针设置为NULL -双重删除保护//不错
第三种方法我不清楚:放一行进去能得到什么 A{…} ?
例如，下面这段奇怪的代码:
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++;
使用第一个版本的好处是什么?
当前回答
我的2 c:
使用缩进
很明显
永远不要依赖运算符优先级——总是使用括号
我不会使用“从不”和“总是”这样的词，但总的来说，我认为这条规则是有用的。在某些语言(Lisp, Smalltalk)中，这不是问题。
总是使用{}块-即使是单行
我从来没有这样做过，也从来没有遇到过任何问题，但我可以看到它对学生有什么好处，特别是如果他们以前学过Python的话。
Const对象在比较的左边
尤达条件?不,请。它损害了可读性。在编译代码时使用最大警告级别即可。
对于>= 0的变量使用unsigned
好的。有趣的是，我听到斯特劳斯特鲁普不同意。
删除后将指针设置为NULL -双重删除保护
坏的建议!永远不要使用指向已删除或不存在的对象的指针。
其他回答
wrt 6:它更安全，因为删除空指针是一个无操作。因此，如果您碰巧两次经过这条路径，您不会因为释放空闲内存或已分配给其他内存而导致内存损坏。
这是静态文件作用域对象和单例对象的主要问题，它们没有非常明确的生命周期，并且已知它们在被销毁后会被重新创建。
在大多数情况下，您可以通过使用auto_ptrs来避免这种需要
如果你是一个编译器，这没有任何区别。两者是一样的。
但是对于程序员来说，第一个更清晰，更容易阅读，更不容易出错。
另一个添加花括号的例子。
有一次我在搜索一个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;
}
它是非常明显的，快速编码器一眼就能发现它。
我正在处理的代码库被那些病态地厌恶大括号的人分散在代码中，对于后来的人来说，它确实可以对可维护性产生影响。
我遇到的最常见的问题是:
if (really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
this_looks_like_a_then-statement_but_isn't;
所以当我出现并希望添加一个then语句时，如果我不小心，我很容易以这样的方式结束:
if (really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
this_looks_like_a_then-statement_but_isn't;
i_want_this_to_be_a_then-statement_but_it's_not;
}
考虑到添加大括号需要1秒左右的时间，并且可以为您节省至少几分钟的调试时间，为什么不选择减少歧义性呢?在我看来这是虚假的节约。
有许多可能的方法来编写控制语句;它们的某些组合可能共存而不损害易读性，但其他组合将引起麻烦。的风格
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开头的语句将提供一个清晰的视觉指示，表明有不寻常的地方。
