使用没有花括号的 if 语句是一种不好的做法吗？ [关闭]

Posted 2023-02-23

【中文标题】使用没有花括号的 if 语句是一种不好的做法吗？ [关闭]

【英文标题】：Is it a bad practice to use an if-statement without curly braces? [closed]

【发布时间】：2011-01-08 15:57:24

【问题描述】：

我见过这样的代码：

if(statement)
    do this;
else
    do this;

不过，我认为这更具可读性：

if(statement)
    do this;
else
    do this;

由于这两种方法都有效，这仅仅是使用哪种方法的偏好问题，还是推荐一种方法而不是另一种方法？

【问题讨论】：

Why is it considered a bad practice to omit curly braces?的可能重复

在我看来这很糟糕，因为您开始依赖几乎从未完全一致的空白缩进。当他们不得不担心这些事情时，它会打乱读者的思路。

使用它是一个好习惯> blog.codecentric.de/en/2014/02/curly-braces

【参考方案1】：

第一个版本的问题是，如果您返回并在 if 或 else 子句中添加第二条语句而不记得添加花括号，您的代码将以意想不到的有趣方式中断。

在可维护性方面，使用第二种形式总是更聪明。

编辑：Ned 在 cmets 中指出了这一点，但我认为这里也值得链接。这不仅仅是一些象牙塔假设的废话：https://www.imperialviolet.org/2014/02/22/applebug.html

【讨论】：

而且您应该始终为可维护性编写代码。毕竟，我很确定编译器并不关心你使用哪种形式。但是，如果您因为愚蠢的花括号错误而引入错误，您的同事可能会很生气。

或者您可以使用一种不使用括号作为代码块的语言...

@lins314159 - 不，我的意思是像 python。因为我在这方面是大男子主义的。

进一步证明错误可能（并且确实）发生：imperialviolet.org/2014/02/22/applebug.html

声称 SSL 错误是支持大括号的论据是不诚实的。并不是说开发人员打算写if (…) goto L; goto L; 而是忘记了大括号。 `if (...) goto L; 纯属巧合。转到 L; ` 恰好不是一个安全漏洞，因为它仍然是一个漏洞（只是不是一个具有安全后果的漏洞）。在另一个例子中，事情可能会朝着相反的方向发展，无括号的代码可能会意外安全。在第三个示例中，无括号代码最初是没有错误的，开发人员在添加括号时会引入错字。

【参考方案2】：

我遵循的“规则”是这样的：

如果“if”语句正在测试以做某事（即调用函数、配置变量等），请使用大括号。

if($test)

    doSomething();

这是因为我觉得你需要弄清楚哪些函数被调用，程序的流程在哪里，在什么条件下。让程序员准确了解在这种情况下调用了哪些函数以及设置了哪些变量，这对于帮助他们准确了解您的程序在做什么很重要。

如果“if”语句正在测试以停止做某事（即循环或函数内的流控制），请使用单行。

if($test) continue;
if($test) break;
if($test) return;

在这种情况下，对程序员来说重要的是快速发现哪些异常情况是您不希望代码运行的地方，而这一切都包含在 $test 中，而不是在执行块中。

【参考方案3】：

我更喜欢使用花括号。但有时，三元运算符会有所帮助。

代替：

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;

如果你把花括号放进去会更好。

【参考方案4】：

这是一个偏好问题。我个人使用这两种样式，如果我有理由确定不再需要添加语句，我会使用第一种样式，但如果可能的话，我会使用第二种。由于您无法在第一种样式中添加更多语句，因此我听说有些人建议不要使用它。但是，第二种方法确实会产生额外的代码行，如果您（或您的项目）使用这种编码风格，那么第一种方法对于简单的 if 语句来说是非常受欢迎的：

if(statement)

    do this;

else

    do this;

但是，我认为这个问题的最佳解决方案是在 Python 中。使用基于空格的块结构，您没有两种不同的方法来创建 if 语句：您只有一种：

if statement:
    do this
else:
    do this

虽然确实存在根本无法使用大括号的“问题”，但您确实获得了好处，即第一种样式不再有行，并且它具有添加更多语句的能力。

【讨论】：

我个人认为 Python 处理 if-else 语句的方式非常丑陋，但话又说回来，我还不是 Python 程序员

【参考方案5】：

我个人的偏好是混合使用空格和括号，如下所示：

if( statement ) 

    // let's do this

 else 

    // well that sucks

我认为这看起来很干净，使我的代码非常易于阅读，最重要的是 - 调试。

【参考方案6】：

根据我的经验，第一种形式唯一（非常）轻微的优势是代码可读性，第二种形式增加了“噪音”。

但是对于现代 IDE 和代码自动生成（或自动完成），我强烈建议使用第二种形式，您不会花费额外的时间输入花括号，并且可以避免一些最常见的错误。

有足够的耗能虫子，人们不应该打开门浪费时间。

编写代码时要记住的最重要的规则之一是一致性。无论是谁编写的，每一行代码都应该以相同的方式编写。严谨可以防止错误“发生”;)

这与清晰明确地命名您的变量、方法、文件或正确缩进它们是一样的......

当我的学生接受这个事实时，他们不再与自己的源代码作斗争，他们开始将编码视为一项非常有趣、刺激和创造性的活动。他们挑战的是他们的思想，而不是他们的神经！

【参考方案7】：

我更喜欢使用大括号。添加大括号使其更易于阅读和修改。

这里有一些大括号的使用链接：

Prefer Multiline if

Omitting Braces: Not Just A Matter Of Style

Stack Overflow

【参考方案8】：

省略语句块的一个问题是else-ambiguity。那就是受 C 启发的语言忽略缩进，因此无法将其分开：

if(one)
    if(two)
        foo();
    else
        bar();

从这里：

if(one)
    if(two)
        foo();
else
    bar();

【讨论】：

这是一个比顶部答案中提到的问题严重得多的问题（添加第二条语句）。

确实，这个答案实际上让我从愤世嫉俗地阅读这些答案到有点担心我实际上可能犯了这个错误。

如果其他人想知道我是 C 实际解释它的哪种方式，我用 GCC 做的测试以第一种方式解释这段代码。 tpcg.io/NIYeqx

“歧义”是错误的术语。解析器将如何看到这一点没有任何歧义：else 贪婪地绑定到最近的最里面的if。问题出现在 C 或类似语言由不知道这一点、不考虑它或还没有喝够咖啡的人编写的地方——所以他们编写了他们认为可以做一件事的代码，但是语言规范说解析器必须做其他事情，这可能会非常不同。是的，这是另一个支持始终包含大括号的坚如磐石的论点，即使语法将它们标记为理论上“不必要”。

【参考方案9】：

我个人使用第一种样式只会抛出异常或过早地从方法返回。就像函数开头的参数检查一样，因为在这些情况下，我很少有不止一件事情要做，而且从来没有其他事情。

例子：

if (argument == null)
    throw new ArgumentNullException("argument");

if (argument < 0)
    return false;

否则我使用第二种样式。

【参考方案10】：

所有 if 语句都使用大括号，即使是简单的语句。或者，重写一个简单的 if 语句以使用三元运算符：

if (someFlag) 
 someVar= 'someVal1';
 else 
 someVar= 'someVal2';

这样看起来好多了：

someVar= someFlag ? 'someVal1' : 'someVal2';

但只有在您绝对确定 if/else 块中没有其他内容时才使用三元运算符！

【参考方案11】：

我同意大多数答案，因为最好在代码中明确并使用大括号。我个人会采用一套编码标准，并确保团队中的每个人都知道并遵守这些标准。在我工作的地方，我们使用IDesign.net 发布的用于 .NET 项目的编码标准。

【参考方案12】：

从一开始就使用大括号应该有助于防止你不得不调试这个：

if (statement)
     do this;
else
     do this;
     do that;

【讨论】：

这似乎是公认的理由，但是（在这里扮演魔鬼的拥护者）难道不是一个额外的语法高亮规则也可以解决这个问题，同时节省一行吗？

因此，当您点击; 时，会有一个 IDE 可以更正缩进 :)

为什么一个懂C的程序员不会注意到，在第二个do that之后没有？丢失的支架会立即触发我。只有 Python 开发人员会爱上这个。如果 C 中的代码没有新作用域的迹象，则它没有形成新作用域，它通常用于表示上一行的继续，即使上一行是 else。

【参考方案13】：

我的一般模式是，如果它适合一行，我会这样做：

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 代码错误）。

再多的括号也无法让维护者免于使用他的大脑。我支持“没有括号，如果它适合一行”的想法，因为，对我来说，这样的 if 只是 三元 if 运算符 的一个版本，不需要在其中做任何事情三元的“后：”部分。为什么有人会在 三元 if 中引入括号？

我完全不同意它最终是主观的，也不同意它只会影响风格和可读性。作为一个浪费时间尝试调试问题的人，事实证明这是由于缺少块分隔符（并且没有注意到它们的缺失）引起的，因为我不得不使用一种在“不必要”时忽略它们的编码风格 - 并且他已经阅读了许多可以说是由这种编码风格引起的可怕错误——我认为这是一个非常客观、实际的问题。当然，使用强制分隔符的样式，我们仍然可以忘记它们，但可以肯定 - 至少 - 肌肉记忆使我们不太可能忘记它们。

等到应用美化剂并且您的 1-liner 是 2-liner。只需使用大括号。

【参考方案14】：

我正在使用我使用的 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;

【讨论】：

这是一个完全主观的风格问题，我个人不喜欢大括号行的冗余。但是，嘿。

我支持这种风格。大多数人从左到右阅读代码，这有点让我们的眼睛固定在屏幕的左边缘。它有助于在视觉上将代码分离并提取到步骤的逻辑块中。

我一直喜欢这种风格。更容易找到相应的右括号。所以它需要很多空间？使用较小的字体。

当大括号位于不同的行时，我总是发现更容易“扫描”代码。这适用于一切；类、方法、if 和 while 语句等。从来不喜欢将第一个大括号放在同一行...

空白很便宜，尤其是当你有一个支持代码折叠的 IDE 时。

【参考方案15】：

我一直试图使我的代码标准并且看起来尽可能接近相同。这使得其他人在负责更新它时更容易阅读它。如果您执行第一个示例并在中间添加一行，它将失败。

不起作用：

如果（语句） 做这个; 和这个; 别的 这样做；