ChatGPT解决这个技术问题 Extra ChatGPT

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

关闭。这个问题是基于意见的。它目前不接受答案。想改进这个问题?更新问题,以便可以通过编辑这篇文章用事实和引用来回答它。 7年前关闭。改进这个问题

我见过这样的代码:

if(statement)
    do this;
else
    do this;

但是,我认为这更具可读性:

if(statement){
    do this;
}else{
    do this;
}

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

在我看来,这很糟糕,因为您开始依赖几乎从未完全一致的空白缩进。当他们不得不担心这些事情时,它会打乱读者的思路。
使用它是一个好习惯> blog.codecentric.de/en/2014/02/curly-braces

c
clee

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

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

编辑:内德在评论中指出了这一点,但我认为也值得在这里链接。这不仅仅是一些象牙塔假设的废话: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; }` 恰好不是安全错误,因为它仍然是一个错误(只是没有安全后果)。在另一个例子中,事情可能会朝着相反的方向发展,无括号的代码可能会意外安全。在第三个示例中,无括号代码最初是没有错误的,开发人员在添加括号时会引入错字。
d
doynax

省略语句块的一个问题是 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 或类似语言由不知道这一点、不考虑它或还没有喝够咖啡的人编写的地方——所以他们编写的代码他们认为会做一件事,但是语言规范说解析器必须做其他事情,这可能会非常不同。是的,这是另一个支持始终包含大括号的坚如磐石的论点,即使语法将它们标记为理论上“不必要的”。
从我所看到的(“悬而未决的问题”)来看,人类可读的语法是模棱两可的,但是解析器默认为提到的选项,或者语法被重写为可读性较低但明确。
M
Matchu

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

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。只需使用大括号。
M
Marcus Harrison

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

如果“if”语句正在测试以执行某些操作(IE 调用函数、配置变量等),请使用大括号。

if($test)
{
    doSomething();
}

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

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

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

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


P
Pentium10

我正在使用我使用的 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 时。
M
Matt Bishop

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

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

这似乎是公认的理由,但是(在这里扮演魔鬼的拥护者)难道不是一个额外的语法高亮规则也可以解决这个问题,同时节省一行?
因此,当您点击 ; 时,拥有一个可以纠正缩进的 IDE :)
为什么一个懂 C 的程序员不会注意到,在第二个 do that 之后没有 }?丢失的支架会立即触发我。只有 Python 开发人员会爱上这个。如果 C 中的代码没有新作用域的迹象,则它没有形成新作用域,它通常用于表示上一行的继续,即使上一行是 else
l
leepowers

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

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

像这样看起来好多了:

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

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


C
Community

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

以下是一些使用大括号的链接:

首选多行如果

省略大括号:不仅仅是风格问题

堆栈溢出


t
thomas.g

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

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

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

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

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

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


N
Nate Heinrich

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

例子:

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

if (argument < 0)
    return false;

否则我使用第二种风格。


G
Grant Paul

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

if(statement)
{
    do this;
}
else
{
    do this;
}

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

if statement:
    do this
else:
    do this

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


我自己认为 Python 处理 if-else 语句的方式非常丑陋,但话又说回来,我还不是 Python 程序员
J
Joe

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

不会工作:

如果(语句)这样做;和这个;否则这样做;


S
Simon

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

if( statement ) {

    // let's do this

} else {

    // well that sucks

}

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


K
Kane

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


f
fastcodejava

我更喜欢放一个花括号。但有时,三元运算符会有所帮助。

代替 :

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;

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