什么时候建议使用ret_val变量？

关于以下代码是否更好,我看到了相互矛盾的建议

def function():
    ret_val = 0
    if some_condition():
        ret_val = 2
    else:
        ret_val = 3
    return ret_val

或者这是否更好:

def function():
    if some_condition():
        return 2
    else:
        return 3

这是一个简单的例子,我用python风格编写它,但我正在寻找的一般原则是什么时候使用一些"累加器"变量来跟踪返回值,或者是否使用多个出口点.我知道不同的语言可能有不同的原因使用一种风格而不是另一种风格,所以我很欣赏不同的观点,为什么特定的语言可能会坚持特定的风格.(特别是在过去,我听说C中的结构化编程避免了函数的多个退出点.)

1> PaulMcG..：

---

我们忘记了为什么"多个出口点"首先被认为是有害的吗？回到当天(在广泛访问良好的异常处理和最终构造之前,或管理auto_ptr那些在离开作用域时进行清理的对象之前),这是困扰许多多退出函数的问题:

int function blah(arg1, arg2)
    allocate resource

    if early failure detection
        return failure_status

    ... much later...

    release resource // oh rats! resource didn't release
    return success_status

如果资源是内存,则会产生内存泄漏.如果它是数据库事务,我们正在走向错误的数据库争用或死锁.就此而言,随着更多异常支持的出现,我们隐式地从方法中添加了许多潜在的退出(由于未处理的异常).在我的C++时代,我养成了从不调用delete 的习惯,而是使用了auto_ptr,以便在auto_ptr退出其范围时清理已分配的内存,即使某些意外的异常抬头.

在我们的垃圾收集Python世界中,我们仍然可以遇到这个问题,即使我们的许多对象(如文件或锁)都改进了自清洁行为.但是在CPython以外的实现中(jython和IronPython命名为2),不能保证析构函数何时被调用,因此需要在方法中构建更主动的东西.为此目的的第一个机制是try/finally:

int function blah(arg1, arg2)
    allocate resource
    try:

        if early failure detection
            return failure_status

        ... much later...
        return success_status

    finally:
        release resource // always releases no matter what

但是现在Python有了上下文管理器,结合了新的'with'语法:

int function blah(arg1, arg2)
    allocate resource
    with context_manager(resource): // releases on exit from 'with'

        if early failure detection
            return failure_status

        ... much later...
        return success_status

因此,让我们确定我们告诉整个故事,我们可以抛弃这个旧板栗的原因是新的编码实践使它变得不必要.

2> Martin v. Lö..：

---

在Python中,在函数中间有一个return语句是很常见的 - 特别是,如果它是早期退出.您的示例通常被重写为

def function():
    if some_condition():
        return 2
    return 3

也就是说,如果if以return结束,则删除else.

3> John Milliki..：

---

除非绝对不可避免,否则不要使用蓄电池.它会在您的过程中引入不必要的有状态和分支,然后您必须手动跟踪它们.通过提前返回,您可以减少代码的状态和分支计数.

特别是在过去,我听说C语言中的结构化编程避免了函数的多个退出点.

恰恰相反,结构化的编程阻碍了多个入口点,但多个退出点是可以接受的,甚至是鼓励的(例如"保护条款").

---

+1.当人们仍然坚持"单一退出点"的格言时,我强烈反对.这种技术对我来说从未特别有意义.由于方法应该很短,您应该能够在屏幕上看到所有出口点.听,听,这个.

---

@snicker:"单一退出点"的哲学是对各种好主意的货币崇拜错误表达,包括Dijkstra对GOTO声明的警告.如果你遇到鼓励使用累加器的人,可以放弃他们的意见是安全的.