如您所知,在Eclipse中,您可以启用“不必要的'else'语句”检查将在 if-then-else 上触发过早返回。而且,根据我的经验,使用这样的陈述时有两种最可能的情况:
1)预先检查:
if (!validate(arg1)) {
return false;
}
doLotOfStuff();
2)事后检查:
doLotOfStuff();
if (condition) {
return foo;
} else {
return bar;
}
在第二种情况下,如果触发器打开,Eclipse将建议您将代码更改为:
doLotOfStuff();
if (condition) {
return foo;
}
return bar;
但是,我认为带有 else 语句的 return 更具可读性,因为它类似于业务逻辑的直接映射。如果这个“不必要的'其他'声明”代码约定很普遍,或者使用 else 语句的代码更优选,那么我很好奇吗?
答案 0 :(得分:18)
通常我更喜欢代码的结构遵循底层“业务”逻辑的结构。在这种情况下,我的方法将取决于condition
所代表的内容。如果是错误检查,例如,通常不会被命中但偶尔会被使用,那么第二种形式的不对称性与逻辑的不对称性相匹配。
doLotOfStuff();
if (condition) {
return foo;
}
return bar;
但是,如果任何一种可能性是合理的并且只是它们之间的选择,我会允许代码结构显示对称性。
doLotOfStuff();
if (condition) {
return foo;
} else {
return bar;
}
代码可供程序员阅读,而不是编译器。
答案 1 :(得分:11)
曾经考虑过(可能仍然是某些人)函数应该有一个入口点(当你考虑汇编语言时很容易但是相关)和一个出口点。
从调试的角度来看,一个退出点是很好的(因为你可以在一条线上放一个手表/休息并且知道你会经历它)但是可能会导致一些可怕的嵌套,所以往往更容易获得可读性出。哪个产生最少的嵌套,最少的代码行和最可读的最终结果?最终,这往往比其他任何事情都重要得多。
对于它的价值,最后可以更好地表达为:
return condition ? foo : bar;
假设condition
不是很长。
不要过分担心所谓的代码“纯度”。这是一种无关紧要的分心。使事物可读并且通常是一致的。
答案 2 :(得分:4)
嗯,一些着名的Java专家认为,应该总是争取最小化事物的范围,这也是我的意见。
我在大学的老师总是折磨着我,我必须写下这样的东西,就像之前发布的那样:
String result = null;
doLotOfStuff();
if (condition) {
result = foo;
} else {
result = bar;
}
return result;
变量结果现在具有相当大的范围。除了大量的嵌套之外,如果你在这里多做一点,这往往会变得非常难以理解,比如你有另一个for循环。
我认为这要好得多:
doLotOfStuff();
return condition ? foo : bar;
这是直截了当的。我立即看到发生了什么,没有检查花括号。
我觉得
非常好“不必要的其他声明”警告有助于此。
答案 3 :(得分:3)
好吧,我认为使用多次返回是不可读的。
我更喜欢代码:
String result = null;
doLotOfStuff();
if (condition) {
result = foo;
} else {
result = bar;
}
return result;
多次退货很难理解。 但在你的情况下,我更喜欢postCheck
doLotOfStuff();
if (condition) {
return foo;
} else {
return bar;
}
答案 4 :(得分:3)
我找到了这个表格
doLotOfStuff();
if (condition) {
return foo;
}
return bar;
比使用else的那个更具可读性,如果你把它看作是福勒的重构中的守卫声明,它的代码更少,更直观。
答案 5 :(得分:2)
我知道如果没有IDE为我检查这个,我几乎总是使用不必要的else语句。我经常发现它最初用它读起来更好,但通常在指出它时将其删除,因为我可以看到这是不必要的事实然后它会让我感到烦恼......
答案 6 :(得分:1)
称我为坏男孩,但我通常会选择:
doLotOfStuff();
return condition ? foo : bar;
单一退货声明,非常易读。
答案 7 :(得分:1)
在我看来,日食检查不是很有用。你应该做什么取决于你的程序环境。其他条款用于替代(或者这个或那个),而下降到一个返回(没有else子句)更适合你有许多条件可能是真的而且这个漏洞更像是你没有的默认反应真的经常调用。所以你在传达意义的代码中使用它们,因此检查是否存在是没有用的。
答案 8 :(得分:0)
一些程序员声称在功能中间return
是不好的做法。也许在第一个例子中可以轻松检查功能输入,这是可以接受的,但在其他情况下,我更喜欢设置result
变量,就像在Jerome响应中一样。
答案 9 :(得分:0)
如果我跟踪下面的代码,我会注意到第一个if-block是一个特殊的代码块。但是,如果我添加“else”,我可能会认为它们都是可操作的代码块。
此外,对于主操作块,可能存在一些嵌套块。我更喜欢最小化嵌套级别。
public String myMethod(input) {
if (!validate(input)) {
return "invalid input";
}
operation1();
if (someCondition) {
operation2();
} else {
operation3();
}
operation4();
operation5();
return operation6();
}