我之前写过一份代码规范文件，其中规定“必须始终使用大括号来控制循环和条件代码块，即使（尤其是）只有一行代码。”
例如：
// this is wrong
if (foo)
//bar
else
//baz
while (stuff)
//things
// This is right.
if (foo) {
// bar
} else {
// baz
}
while (things) {
// stuff
}
如果你不在单行代码中使用大括号，然后有人将其注释掉，那么你就会遇到麻烦。如果你没有使用大括号来包围单行代码，并且缩进在其他人的机器上显示不同... 那么你就会遇到麻烦。
所以问题是：这个标准存在错误或者不合理的原因吗？目前已经有一些讨论，但是没有人能够提供比“看起来不好看”更好的反驳意见。
if只会影响调试打印语句而不是它下面的其他语句。在调试代码时，我曾因不遵守花括号规则而踩过这个坑，不止一次。 - Nathan Fellman对于if语句，如果其结果为return或continue循环，则我会做一些小的例外，除此之外我会强制执行这个标准。
所以，按我的标准，以下是正确的：
if(true) continue;
就像这个样子
if(true) return;
但是规则是要么使用return或continue，并且它们必须在同一行上。否则，就需要用括号包裹。
这样做的原因既是为了有一个标准的做法，也是为了避免你提到的注释问题。
if (true) break; 来终止循环。 - Jonathan Leffler我认为这个规则过于严格。强制使用一种方法并不能培养出好的程序员，它只是降低了粗心大意者犯错的几率。
你提供的例子是有道理的，但是有比强制使用花括号更好的解决方案：
如果你不给单行语句加花括号，某个人注释掉时就会出现问题。
有两种做法可以更好地解决这个问题，请选择其中之一：
1）在单行语句前面的if、while等地方加注释。例如，请将：
if(foo)
bar();
就像其他多行语句一样（例如，具有多行的赋值语句或多行函数调用）：
//if(foo)
// bar();
2）在//前加上;：
if(foo)
;// bar();
如果你没有为单行代码加上括号，且在别人的机器上缩进显示不一致……你就会遇到麻烦。
不是这样的，代码依然可用，但难以阅读。请修复缩进问题，选择使用制表符或空格并坚持使用。千万不要混合使用制表符和空格进行缩进，因为很多文本编辑器可以自动帮助您解决此问题。
写一些Python代码可以纠正一些不良缩进习惯。
另外，像} else {这样的结构对我来说看起来像TIE战斗机的nethack版本。
有没有好的理由可以证明这是一个错误或不合理的标准？虽然有一些讨论，但没有人能给出比“感觉难看”更好的反驳意见。
多余的大括号（和括号）是视觉上的杂物。视觉杂物会使代码变得难以阅读。代码越难以阅读，隐藏漏洞就越容易。
int x = 0;
while(x < 10);
{
printf("Count: %d\n", ++x);
}
强制使用大括号并不能帮助找到上面代码中的错误。
P.S. 我是“每条规则都应该有其原因”的支持者，或者如达赖喇嘛所说，“要知道规则，才能正确地打破它们。”
我还没有听到任何一个不使用大括号的好理由。
我听到的任何“感觉丑陋”的理由都无法与其带来的好处相比。
编码规范的存在是为了让代码更易于阅读和减少错误。
这是一项真正值得付出的标准。
!!被认为是一致的）。 - Sam Harwell// This is right.
if (foo)
{
// bar
}
else
{
// baz
}
while (things)
{
// stuff
}
我认为遵循编码规范以减少错误并使代码更易读是无可厚非的。虽然一开始可能会让一些人感到不舒服，但我认为这是完全有效的实施规则。
我的个人规则是，如果条件语句很短，则将其全部放在一行上：
if(!something) doSomethingElse();
通常只有在连续出现一堆像这样的if语句时，我才会使用它。
if(something == a) doSomething(a);
if(something == b) doSomething(b);
if(something == b) doSomething(c);
不过这种情况并不经常发生，所以除此之外，我总是使用大括号。
目前，我与一个遵循这个标准的团队合作，虽然我对此持抵触态度，但为了统一性而遵守。
我反对禁止使用异常、模板或宏的团队，理由相同：如果你选择使用一种语言，就要使用整个语言。如果在C、C++和Java中花括号是可选的，那么通过惯例强制使用它们表明对语言本身有些恐惧。
我理解其他答案中描述的危险，并理解对统一性的渴望，但我不赞同语言子集，除非存在某些严格的技术原因，例如某些环境中唯一的编译器不支持模板，或者与C代码的交互阻止广泛使用异常。
我的大部分时间都用来审核初级程序员提交的更改，常见的问题与花括号的位置或语句放错地方无关。这种危险被夸大了。我宁愿把时间花在解决更重要的问题上，而不是寻找编译器可以轻松接受的违规行为。