我在读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++;
使用第一个版本的好处是什么?
当前回答
因为当你有两个没有{}的语句时，很容易漏掉一个问题。让我们假设代码是这样的。
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;
其他回答
帮助防止在前面的回答中描述的错误的一个选项是内联您希望在不使用大括号时发生的事情。当您尝试修改代码时，很难不注意到错误。
if (condition) doSomething();
else doSomethingElse();
if (condition) doSomething();
doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong
因为当你有两个没有{}的语句时，很容易漏掉一个问题。让我们假设代码是这样的。
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;
在“总是使用牙套”的营地呆了10年之后，我最近开始不怎么使用牙套了。 主要是受到Bob叔叔关于如何编写干净代码的争论的启发，我现在相信不使用大括号编写代码更具有可读性。
if(guardClause)
throw new SomeException(..)
Bob大叔认为，在if/for语句中编写多行代码是潜在的可读性问题。
e.g.
if(someCondition)
{
doTechnicalThingX();
doTechnicalThingY();
doTechnicalThingZ();
}
应该被重构为
if(someCondition)
doFunctionalThingA();
对我来说，不把大括号放在那里是有帮助的，因为我得到提醒，我在if块中写了太多代码。
正如其他人所提到的，我相信代码风格是团队决策。
它通过清楚地定义循环和条件块的范围，使您的代码更具可读性。它还可以避免你意外出错。
我能想到的最贴切的例子是:
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).
