我见过这样的代码：
if(statement)
do this;
else
do this;
不过，我认为这更具可读性：
if(statement){
do this;
}else{
do this;
}
由于这两种方法都有效，这仅仅是使用哪种方法的偏好问题，还是推荐一种方法而不是另一种方法？
【问题讨论】：
标签： if-statement coding-style curly-braces
第一个版本的问题是，如果您返回并在 if 或 else 子句中添加第二条语句而不记得添加花括号，您的代码将以意想不到的有趣方式中断。
在可维护性方面，使用第二种形式总是更聪明。
编辑：Ned 在 cmets 中指出了这一点，但我认为这里也值得链接。这不仅仅是一些象牙塔假设的废话：https://www.imperialviolet.org/2014/02/22/applebug.html
【讨论】：
if (…) { goto L; goto L; } 而是忘记了大括号。 `if (...) { goto L; 纯属巧合。转到 L; }` 恰好不是一个安全漏洞，因为它仍然是一个漏洞（只是不是一个具有安全后果的漏洞）。在另一个例子中，事情可能会朝着相反的方向发展，无括号的代码可能会意外安全。在第三个示例中，无括号代码最初是没有错误的，开发人员在添加括号时会引入错字。
我遵循的“规则”是这样的：
如果“if”语句正在测试以做某事（即调用函数、配置变量等），请使用大括号。
if($test)
{
doSomething();
}
这是因为我觉得你需要弄清楚哪些函数被调用，程序的流程在哪里，在什么条件下。让程序员准确了解在这种情况下调用了哪些函数以及设置了哪些变量，这对于帮助他们准确了解您的程序在做什么很重要。
如果“if”语句正在测试以停止做某事（即循环或函数内的流控制），请使用单行。
if($test) continue;
if($test) break;
if($test) return;
在这种情况下，对程序员来说重要的是快速发现哪些异常情况是您不希望代码运行的地方，而这一切都包含在 $test 中，而不是在执行块中。
【讨论】：
我更喜欢使用花括号。但有时，三元运算符会有所帮助。
代替：
int x = 0;
if (condition) {
x = 30;
} else {
x = 10;
}
应该简单地做：int x = condition ? 30 : 20;
再想象一个案例：
if (condition)
x = 30;
else if (condition1)
x = 10;
else if (condition2)
x = 20;
如果你把花括号放进去会更好。
【讨论】：
这是一个偏好问题。我个人使用这两种样式，如果我有理由确定不再需要添加语句，我会使用第一种样式，但如果可能的话，我会使用第二种。由于您无法在第一种样式中添加更多语句，因此我听说有些人建议不要使用它。但是，第二种方法确实会产生额外的代码行，如果您（或您的项目）使用这种编码风格，那么第一种方法对于简单的 if 语句来说是非常受欢迎的：
if(statement)
{
do this;
}
else
{
do this;
}
但是，我认为这个问题的最佳解决方案是在 Python 中。使用基于空格的块结构，您没有两种不同的方法来创建 if 语句：您只有一种：
if statement:
do this
else:
do this
虽然确实存在根本无法使用大括号的“问题”，但您确实获得了好处，即第一种样式不再有行，并且它具有添加更多语句的能力。
【讨论】：
我个人的偏好是混合使用空格和括号，如下所示：
if( statement ) {
// let's do this
} else {
// well that sucks
}
我认为这看起来很干净，使我的代码非常易于阅读，最重要的是 - 调试。
【讨论】：
根据我的经验，第一种形式唯一（非常）轻微的优势是代码可读性，第二种形式增加了“噪音”。
但是对于现代 IDE 和代码自动生成（或自动完成），我强烈建议使用第二种形式，您不会花费额外的时间输入花括号，并且可以避免一些最常见的错误。
有足够的耗能虫子，人们不应该打开门浪费时间。
编写代码时要记住的最重要的规则之一是一致性。无论是谁编写的，每一行代码都应该以相同的方式编写。严谨可以防止错误“发生”;)
这与清晰明确地命名您的变量、方法、文件或正确缩进它们是一样的......
当我的学生接受这个事实时，他们不再与自己的源代码作斗争，他们开始将编码视为一项非常有趣、刺激和创造性的活动。他们挑战的是他们的思想，而不是他们的神经！
【讨论】：
我更喜欢使用大括号。添加大括号使其更易于阅读和修改。
这里有一些大括号的使用链接：
【讨论】：
省略语句块的一个问题是else-ambiguity。那就是受 C 启发的语言忽略缩进，因此无法将其分开：
if(one)
if(two)
foo();
else
bar();
从这里：
if(one)
if(two)
foo();
else
bar();
【讨论】：
else 贪婪地绑定到最近的最里面的if。问题出现在 C 或类似语言由不知道这一点、不考虑它或还没有喝够咖啡的人编写的地方——所以他们编写了他们认为可以做一件事的代码，但是语言规范说解析器必须做其他事情，这可能会非常不同。是的，这是另一个支持始终包含大括号的坚如磐石的论点，即使语法将它们标记为理论上“不必要”。
我个人使用第一种样式只会抛出异常或过早地从方法返回。就像函数开头的参数检查一样，因为在这些情况下，我很少有不止一件事情要做，而且从来没有其他事情。
例子：
if (argument == null)
throw new ArgumentNullException("argument");
if (argument < 0)
return false;
否则我使用第二种样式。
【讨论】：
所有 if 语句都使用大括号，即使是简单的语句。或者，重写一个简单的 if 语句以使用三元运算符：
if (someFlag) {
someVar= 'someVal1';
} else {
someVar= 'someVal2';
}
这样看起来好多了：
someVar= someFlag ? 'someVal1' : 'someVal2';
但只有在您绝对确定 if/else 块中没有其他内容时才使用三元运算符！
【讨论】：
我同意大多数答案，因为最好在代码中明确并使用大括号。我个人会采用一套编码标准，并确保团队中的每个人都知道并遵守这些标准。在我工作的地方，我们使用IDesign.net 发布的用于 .NET 项目的编码标准。
【讨论】：
从一开始就使用大括号应该有助于防止你不得不调试这个：
if (statement)
do this;
else
do this;
do that;
【讨论】：
; 时，会有一个 IDE 可以更正缩进 :)
do that之后没有}？丢失的支架会立即触发我。只有 Python 开发人员会爱上这个。如果 C 中的代码没有新作用域的迹象，则它没有形成新作用域，它通常用于表示上一行的继续，即使上一行是 else。
我的一般模式是，如果它适合一行，我会这样做：
if(true) do_something();
如果有一个 else 子句，或者如果我想在 true 上执行的代码很长，请一路大括号：
if(true) {
do_something_and_pass_arguments_to_it(argument1, argument2, argument3);
}
if(false) {
do_something();
} else {
do_something_else();
}
归根结底，它归结为风格和可读性的主观问题。然而，一般的编程世界几乎分为两派（对于使用大括号的语言）：要么一直无例外地使用它们，要么一直无例外地使用它们。我属于后者。
【讨论】：
if(true){ do_something(); } 很简单，但为什么要冒险让另一个程序员在未来引入一个严重的错误（查找 Apple 的“goto fail”总 ssl 代码错误）。
我正在使用我使用的 IDE 的代码格式化程序。这可能会有所不同，但可以在首选项/选项中进行设置。
我喜欢这个：
if (statement)
{
// comment to denote in words the case
do this;
// keep this block simple, if more than 10-15 lines needed, I add a function for it
}
else
{
do this;
}
【讨论】：
我一直试图使我的代码标准并且看起来尽可能接近相同。这使得其他人在负责更新它时更容易阅读它。如果您执行第一个示例并在中间添加一行，它将失败。
不起作用：
如果（语句） 做这个; 和这个; 别的 这样做；
【讨论】：