【发布时间】:2020-09-19 09:26:45
【问题描述】:
库的BigInteger.gcd(...) 方法的实现从这些语句开始:
public BigInteger gcd(BigInteger val) {
if (val.signum == 0)
return this.abs();
else if (this.signum == 0)
return val.abs();
...
}
在这种情况下,else 关键字的用途是什么?它只是程序员忘记删除的旧代码的残余,还是以某种方式影响性能?
我理解,在这种特殊情况下,带有和不带有 else 的版本在语义上是相同的。然而,很多时候,我面临着两种选择
<Some method signature>(...) {
if (...) {
<Short branch>
return ...;
} else {
<Long branch>
return ...;
}
}
和
<Some method signature>(...) {
if (...) {
<Short branch>
return ...;
}
<Long branch>
return ...;
}
哪个选项在性能方面更好(注意这个问题是 Java 特有的)?如果两种情况下的性能几乎相同,那么哪一种在可读性方面更好?
【问题讨论】:
-
库实现没有使用大括号
{},所以我不知道我会对他们的特定风格给予多少信任。我也不知道给定代码的年龄。我也不知道任何性能差异(并且 JIT 可能对这两种情况都有优化)。至于可读性,那是主观意见。但我认为if中的短分支然后没有else是最易读的。您还可以分解“长分支”以委托给不同的方法。但这只是我个人的看法。 -
@ElliottFrisch 此代码来自 JDK 8 和 JDK 11(给出的部分相同),顶部的版权行指的是 1996, 2018。关于大括号
{},他们在上面几行中使用了它们。我个人的看法是,单行块不需要它们,但我认为这无关紧要。 -
我认为您可以绝对肯定,JIT 优化涵盖了
if/else用法上的这些细微差别。在可读性方面:我会使用第三个代码 sn-p 用于短方法,使用第二个 sn-p 用于长方法。 -
这是风格和品味的问题。我本可以发现以
gcd()中看到的方式编写代码很自然,只是我会包含大括号。 -
为了它的价值,Eclipse 有一个设置来标记甚至禁止 不必要的 'else' 语句,对于不喜欢在 @ 中完成方式的程序员或团队987654334@。它在 Preferences->Java->Compiler->Errors/Warnings->Unnecessary code 下。
标签: java performance if-statement return readability