方法结束时“return”和java中方法结束之前放置的“return”之间的区别?
如果我们在方法结束之前放置“return”语句,如下面的代码,会发生什么?
boolean sample()
{
boolean b=false;
int a=0;
if(a==0)
return(true); //This return what happens
return(false);
}
是否会增加系统的负担而不是方法结束时的正常“返回”?
答案 0 :(得分:4)
不,它没有任何区别。
有些人喜欢将他们的方法结构化为只有一个return语句,总是在最后 - 我个人倾向于在代码知道结果后立即返回。我发现最终会有更易读的代码,特别是如果你能在某些情况下立即告诉结果 (例如“如果输入为空,输出为空”),但在其他情况下会有重要的处理。
答案 1 :(得分:3)
方法结束时“return”和java中方法结束之前放置的“return”之间的区别?
没有语义差异。
唯一需要注意的是无条件 return语句会导致语句无法访问; e.g。
int a = 0;
return a == 0;
int b = 1; // compilation error here ... statement is unreachable
return b == 1;
是否会增加系统的负担,而不是方法结束时的正常“返回”。
不,不会。如果需要,生成的字节码(和本机代码)可以有多个返回指令。
但是,为了清晰/可读性,最好写下这两个语句:
if (a == 0) return (true);
return (false);
作为单一陈述:
return a == 0;
并且不需要在Java return
语句中使用括号。
答案 2 :(得分:0)
所有回报都是相似的。在您的示例中,您不需要多次返回。
return a == 0;
我建议您不要担心性能问题,直到您可以看到/衡量您遇到问题为止。人们在论坛中担心的大多数性能问题都不会产生任何真正的不同。
答案 3 :(得分:0)
多次返回只是您方法中的多个存在点,它们不会给系统带来任何“额外负担”,它们与“正常”返回没有区别。
该方法在到达第一个返回时将退出,并且在执行return语句后不会执行其他代码。然后,控制将返回到调用方法
答案 4 :(得分:0)
Jon Skeet说的是正确的,如果函数得到了正确的结果,那么让它立即返回结果,而不是等待函数做不必要的检查,循环等。这使得函数得到更快的结果+更好的可读性< / p>
答案 5 :(得分:0)
在方法中进行多次返回没有任何内在错误,这样做可能很优雅。大多数递归函数都会有多个返回:
public String flattenTree(Node currentNode, String stringSoFar) {
// do our work on this node
stringSoFar = stringSoFar + currentNode.getName();
// end condition- if we've got no children left we're done so leave now
if (currentNode.countChildren() ==0) {
return stringSoFar;
}
// recursive condition- keep digging through the children of our current node
for (int i=0; i<currentNode.countChildren(); i++) {
stringSoFar = stringSoFar + flattenTree(currentNode.getChild(i));
}
return stringSoFar;
}
看起来干净整洁,让你清楚地标出你的最终状况......我非常喜欢这种方法,因为它看起来像是被教导在学校做回复......
将其压缩成单一回报没有错:
public String flattenTree(Node currentNode, String stringSoFar) {
// do our work on this node
stringSoFar = stringSoFar + currentNode.getName();
// loop through children if neccessary
for (int i=0; i<currentNode.countChildren(); i++) {
stringSoFar = stringSoFar + flattenTree(currentNode.getChild(i));
}
return stringSoFar;
}
在你的最终案例所在的地方,代码越少,可以说是更好,可以说不那么明显......
在性能方面,我无法声称知道一个人的性能比另一个更高/更低,但我不得不说,除非我正在研究一个超级性能关键的代码,否则我总是选择可读性过度表现,我建议至少在这个假设的例子中,你选择多个回报以便于阅读。