不必要的’其他’声明

如您所知,在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语句返回更具可读性,因为它类似于业务逻辑的直接映射。 如果这个“不必要的’其他’声明”代码约定很普遍,或者使用else语句的代码更优选,那么我很好奇吗?

通常我更喜欢代码的结构遵循底层“业务”逻辑的结构。 在这种情况下,我的方法将取决于condition代表什么。 如果是错误检查,例如,通常不会被命中但偶尔会被使用,那么第二种forms的不对称性与逻辑的不对称性相匹配。

 doLotOfStuff(); if (condition) { return foo; } return bar; 

但是,如果任何一种可能性是合理的并且它只是它们之间的选择,我将允许代码的结构显示对称性。

 doLotOfStuff(); if (condition) { return foo; } else { return bar; } 

代码在那里供程序员阅读,而不是编译器。

曾经考虑过(并且可能仍然是某些人)函数应该有一个入口点(容易但在考虑汇编语言时是相关的)和一个出口点。

从调试的角度来看,一个退出点是很好的(因为你可以在一条线上放置一个监视/rest并且知道你会经历它),但是可能导致一些可怕的嵌套,因此更多的可读性往往会胜出。 哪个产生最少的嵌套,最少的代码行和最可读的最终结果? 最终,这往往比其他任何事情都重要得多。

对于它的价值,最后可以更好地表达为:

 return condition ? foo : bar; 

假设condition不是很长。

不要过分担心所谓的代码“纯度”。 这是一种无关紧要的分心。 使事物可读并且通常是一致的。

好吧,一些着名的Java专家认为,应该总是争取最小化事物的范围,这也是我的意见。

我在大学的老师总是折磨我,我必须写下这样的东西,就像之前发布的那样:

 String result = null; doLotOfStuff(); if (condition) { result = foo; } else { result = bar; } return result; 

变量结果现在具有相当大的范围。 除了大量的嵌套之外,如果你在这里多做一点,这往往会变得非常难以理解,比如你有另一个for循环。

我认为这要好得多:

 doLotOfStuff(); return condition ? foo : bar; 

这很直截了当。 我立即看到发生了什么,没有检查花括号。

我觉得这很好

  • 最小化范围
  • 最小化缩进(避免花括号)
  • 最小化方法长度

“不必要的其他声明”警告有助于此。

好吧,我认为使用多次返回是不可读的。

我更喜欢代码:

 String result = null; doLotOfStuff(); if (condition) { result = foo; } else { result = bar; } return result; 

多次退货很难理解。 但在你的情况下,我更喜欢postCheck

 doLotOfStuff(); if (condition) { return foo; } else { return bar; } 

我找到了这个表格

 doLotOfStuff(); if (condition) { return foo; } return bar; 

为了比使用else的更具可读性,如果你把它看作是福勒的重构中的守卫声明,那么代码就会更少,更直观。

关于多个返回点的问题 。

我知道如果没有IDE为我检查这个,我几乎总是使用不必要的else语句。 通常我发现它最初用它读起来更好,但通常在指出它时将其删除,因为我可以看到它是不必要的事实然后它会让我感到烦恼……

叫我一个坏男孩,但我通常会跟:

 doLotOfStuff(); return condition ? foo : bar; 

单一返回语句,非常易读。

在我看来,日食检查不是很有用。 你应该做什么取决于你的程序上下文。 其他条款用于替代(或者这个或那个),而下降到返回(没有else子句)更适合你有许多条件可能是真的而且这个漏洞更像是你没有的默认反应真的经常调用。 所以你在传达意义的代码中使用它们,因此检查是否存在是没有用的。

一些程序员声称在function中间return是不好的做法。 也许为了在第一个例子中容易检查函数入口,它是可以接受的,但在其他情况下,我更喜欢在Jerome响应中设置result变量。

如果我跟踪下面的代码,我会注意到第一个if-block是一个特殊的代码块。 但是,如果我添加一个“else”,我可能会认为这两个都是可操作的代码块。

此外,对于主操作块,可能存在一些嵌套块。 我更喜欢最小化嵌套级别。

 public String myMethod(input) { if (!validate(input)) { return "invalid input"; } operation1(); if (someCondition) { operation2(); } else { operation3(); } operation4(); operation5(); return operation6(); }