python - 何时建议使用 ret_val 变量？

Question

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

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 中的结构化编程避免了一个函数有多个导出点。)

Answer 1

我们是否忘记了为什么“多个导出点”首先被认为是有害的？回到过去(在广泛访问良好的异常处理和 finally 构造之前，或者管理像 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)，无法保证何时调用析构函数，因此需要在您的方法中构建更主动的东西。用于此目的的第一个机制是 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

所以让我们确保我们讲述了整个故事，我们可以丢弃这个陈词滥调的原因是新的编码实践使它变得不必要了。