是否比if语句更优雅的函数返回?

Iai*_*ain 17 if-statement return

我和一位同事对以下哪一项更优雅存在争议.我不会说谁是谁,所以它是公正的.哪个更优雅?

public function set hitZone(target:DisplayObject):void
        {
            if(_hitZone != target)
            {
                _hitZone.removeEventListener(MouseEvent.ROLL_OVER, onBtOver);
                _hitZone.removeEventListener(MouseEvent.ROLL_OUT, onBtOut);
                _hitZone.removeEventListener(MouseEvent.MOUSE_DOWN, onBtDown);

                _hitZone = target;

                _hitZone.addEventListener(MouseEvent.ROLL_OVER, onBtOver, false, 0, true);
                _hitZone.addEventListener(MouseEvent.ROLL_OUT, onBtOut, false, 0, true);
                _hitZone.addEventListener(MouseEvent.MOUSE_DOWN, onBtDown, false, 0, true);
            }
        }
Run Code Online (Sandbox Code Playgroud)

...要么...

public function set hitZone(target:DisplayObject):void
        {
            if(_hitZone == target)return;

            _hitZone.removeEventListener(MouseEvent.ROLL_OVER, onBtOver);
            _hitZone.removeEventListener(MouseEvent.ROLL_OUT, onBtOut);
            _hitZone.removeEventListener(MouseEvent.MOUSE_DOWN, onBtDown);

            _hitZone = target;

            _hitZone.addEventListener(MouseEvent.ROLL_OVER, onBtOver, false, 0, true);
            _hitZone.addEventListener(MouseEvent.ROLL_OUT, onBtOut, false, 0, true);
            _hitZone.addEventListener(MouseEvent.MOUSE_DOWN, onBtDown, false, 0, true);

        }
Run Code Online (Sandbox Code Playgroud)

xsl*_*xsl 41

在大多数情况下,早期返回会降低复杂性并使代码更具可读性.

它也是Spartan编程中应用的技术之一:

最少使用控制

  1. 通过使用专用结构(例如,类默认值,类一次和类分隔符)来最小化条件的使用,例如三元化,继承和类
  2. 尽早简化条件return.
  3. 通过使用诸如Class Separate和Class FileSystemVisitor之类的动作应用程序类,最大限度地减少循环结构的使用.
  4. 简化迭代的逻辑早期退出(经由return, continuebreak语句).

在您的示例中,我将选择选项2,因为它使代码更具可读性.检查函数参数时我使用相同的技术.

  • 看过斯巴达编程链接后,我不得不说我并不完全喜欢我所看到的.几乎没有空白?简短的变量名称?对于没有花括号的循环?嗯... (3认同)

Mar*_*gel 18

这是可以违反规则(即最佳实践)的情况之一.通常,您希望函数中的返回点尽可能少.实际的原因是它简化了对代码的读取,因为您可以始终假设每个函数都将获取其参数,执行其逻辑并返回其结果.为各种情况提供额外的回报往往会使逻辑变得复杂,并增加了阅读和完全理解代码所需的时间.一旦你的代码到达维护阶段,那么多个返回会对新程序员的生产力产生巨大影响,因为他们试图破译逻辑(当评论稀疏且代码不清楚时,它尤其糟糕).该问题相对于函数的长度呈指数增长.

那么为什么在这种情况下每个人都更喜欢选项2?这是因为您正在设置一个函数,该函数通过验证传入数据或可能需要检查的其他不变量来强制执行.构造验证的最漂亮的语法是检查每个条件,如果条件失效,则立即返回.这样,您不必通过所有检查维护某种isValid布尔值.

总结一下:我们真的在考虑如何编写验证代码而不是一般逻辑; 选项2更适合验证代码.


Jas*_*ins 11

只要早期返回被组织为函数/方法体顶部的块,那么我认为它们比添加另一层嵌套更具可读性.

我尽量避免在身体中间早期返回.有时它们是最好的方式,但大多数时候我认为它们很复杂.

此外,作为一般规则,我尝试最小化嵌套控制结构.显然你可以把这个拿得太远,所以你必须谨慎使用.将嵌套if转换为单个switch/case对我来说更加清晰,即使谓词重复了一些子表达式(并且假设这不是一个语言中的性能关键循环,对于子表达式消除来说太愚蠢).特别是我不喜欢长函数/方法体中嵌套ifs的组合,因为如果由于某种原因跳到代码的中间,你最终会向上和向下滚动以精神重建给定行的上下文.


Zar*_*nen 5

根据我的经验,在项目中使用早期回报的问题是,如果项目中的其他人不习惯它们,他们就不会寻找它们。因此,无论是否提前返回 - 如果涉及多个程序员,请确保每个人至少都知道他们的存在。

我个人编写代码以尽快返回,因为延迟返回通常会带来额外的复杂性,例如尝试安全退出一堆嵌套循环和条件。

因此,当我查看一个不熟悉的函数时,我做的第一件事就是查找所有 s return。真正有帮助的是设置语法着色以提供return与其他任何颜色不同的颜色。(我选择红色。)这样,returns 就成为确定函数功能的有用工具,而不是粗心的人隐藏的绊脚石。