我在读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++;
使用第一个版本的好处是什么?
当前回答
我正在处理的代码库被那些病态地厌恶大括号的人分散在代码中，对于后来的人来说，它确实可以对可维护性产生影响。
我遇到的最常见的问题是:
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 (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秒左右的时间，并且可以为您节省至少几分钟的调试时间，为什么不选择减少歧义性呢?在我看来这是虚假的节约。
让我们尝试在增加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块中写了太多代码。
正如其他人所提到的，我相信代码风格是团队决策。
帮助防止在前面的回答中描述的错误的一个选项是内联您希望在不使用大括号时发生的事情。当您尝试修改代码时，很难不注意到错误。
if (condition) doSomething();
else doSomethingElse();
if (condition) doSomething();
doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong
我认为第一个比第二个更清楚。它给人一种结束指令的感觉。使用短代码是可以的，但是当代码变得复杂时，{…}帮助很大，即使它是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++;
