7

这种宽泛的问题。

当我发现自己不得不编写越来越长的脚本时，我发现我的本能是将所有内容分解成一口大小的函数；然而，这最终导致函数调用函数调用函数调用函数......我想知道我是否完全以错误的方式思考这个问题。

这是删节脚本的样子。对不起，这有点做作。

def simple_task_1():
    return

def simple_task_2():
    return

def simple_task_3():
    return

def simple_task_4():
    return

def complex_task_1():
    simple_task_2()
    simple_task_3()
    simple_task_4()
    return

def startup():
    simple_task_1()
    complex_task_1()
    simple_task_4()

def finish():
    # other function calls
    return

def main():
    startup()
    finish()

那么，这是使用函数的正确方法吗？有没有一个客观的观点，你可以说你在彼此内部进行了太多的函数调用？我是否应该为最终只完成一次的任务创建函数？

4

5 回答 5

7

Python 有一个“递归”限制。如果你做到了，那么你可能使用了太多的函数，否则这可能没什么大不了的——通常你只能在递归调用函数时达到递归限制（然后通常是因为你做错了什么并且当你应该有的时候没有打破）。

功能的重点是让您的生活更轻松。如果你发现你有太多的功能并且你实际上并没有让你的生活更轻松，那么这可能是一个问题。例如：

def add(x,y):
    return x+y

是一个非常没有意义的功能，但是如果您愿意，最好避免使用它sinc：

def sinc(x):
    return math.sin(x)/x

这实际上可能很有用，因为新函数名称比其中执行的代码更具描述性。此外，稍后如果您发现需要删除 x=0 处的奇点，您可以sinc轻松地将其添加进去。

最终，可读性才是最重要的。如果使用函数使您的代码更易于阅读，那么它可能是值得的（即使您只从一个地方调用它并且可以轻松地内联它）。如果您真的关心性能，则存在一些灰色区域（函数的执行时间确实比内联代码要长一些），但是您不应该以此为借口来内联难以阅读的内容，除非您可以可靠地证明这是一个性能瓶颈。

于 2012-12-11T21:00:12.727 回答
3

将大的东西分解成更小的东西，无论是模块、类、函数等，这正是处理软件复杂性的方法。分而治之。

于 2012-12-11T21:18:44.073 回答
2

函数的要点是允许代码重用和更简洁的代码。如果您只做一次真的很简单，那么该功能可能是不必要的。

话虽如此，将代码拆分为函数外观并没有明显的错误。如果它使您的生活更轻松或您的代码更具可读性，那么请继续使用它们。

于 2012-12-11T21:03:38.007 回答
1

看起来不错，至少在抽象方面。

将程序精确分解为函数取决于函数的功能，但如果最终结果由函数组成，每个函数都执行一项由函数名称完整描述的任务，那么您就走在了正确的轨道上。

如果您发现自己拥有大量具有逻辑分组的函数，您可能会考虑将它们划分为模块。如果你有很多函数使用相同的数据，你可以考虑创建一个类来保存数据和相应的函数。

于 2012-12-11T21:04:06.163 回答
1

你正在做一个权衡。通常，将代码模块化是一件好事。大多数人做得不够。它增加了代码的可重用性和（通常）可读性。但它可能会走得太远：如果您发现自己对哪些函数调用哪些函数感到困惑，并且可读性开始下降，您可能需要重新考虑您的设计。

要注意的另一件事是调用函数需要大量开销，这可能很重要。每次调用函数时，都必须创建一个激活记录并将其放置在调用堆栈中。对于简单得离谱的函数，这种开销是不值得的。例如，如果您正在实现一个需要 2 个数字的平均值的排序函数（也许选择快速排序的枢轴？），您最好只编写(a+b)/2而不是定义一个函数

def avg(a, b):
    return (a+b)/2

您提出了一个非常好的问题，这绝对是您应该不断思考的问题，但显然很难给出具体的答案。当您编写越来越多的代码时，您会对它有更好的感觉。

于 2012-12-11T21:06:01.100 回答