效率与代码的易读性？

Question

假设我有一个简单的函数，它计算一个数字的立方根并将其作为字符串返回：

def cuberoot4u(number):

    return str(pow(number, 1/3))

我可以改写为：

^{pr2}$

后一个版本有声明额外变量的额外步骤，这些变量通过每个操作显示值；乘以1/3并转换为字符串-代码看起来更容易理解。在

现在，对于这样一个寻找库贝罗特的卑微任务来说，这两个功能对外行来说都是不言而喻的。但是，如果函数做的事情要复杂得多，涉及到几十或几百个代数操作或其他一些类型的操作，那么在什么情况下，我们应该简单地将所有这些都写在函数的return部分，或者更详细地说明主体中的所有步骤，如上面的第二个例子？在

据我所知，该函数的第一个版本似乎不太清晰，但效率更高。在本例中，如何以及何时在代码的易读性和效率之间取得平衡？在

Answer 1

1. 总是优先考虑可读性。

2. 总是优先考虑可读性。

3. 过早的优化是有害的。因此，始终优先考虑可读性。

4. 一旦你的代码是可读的，如果性能是一个问题，或者如果它成为一个问题，在优化任何之前对代码进行评测。你不想浪费时间和降低可读性优化一些不会给你带来太多好处的东西。

5. 首先，对优化后仍然可读性很强的内容进行优化；例如，将方法绑定到局部变量。在

   1. 这些方法往往不会提高太多的性能（尽管将方法绑定到局部变量在某些代码中会有很大的不同），但有时您可以看到一些更高效、更具可读性的东西，而这正是您之前错过的。

   2. 可读性的降低是否值得性能的提高是主观的，取决于每一个在特定情况下的重要性。

6. 然后，如果仍然需要优化，开始将要优化的代码部分分解成函数；这样，即使它们已经过优化并且可读性降低，主代码仍然是可读的，因为它只是调用函数do_something()，而不必担心丑陋，优化了该函数中的代码块。在

   1. 我认为这是一个好的事情，即使有可读的代码，使它更可读。在

7. 如果每一点性能都有帮助，那么您可能希望将函数重新内联到主代码中。这取决于您使用的Python实现，例如CPython和PyPy。

8. 如果一大堆优化到地狱的Python代码不够快。。用C重写

   1. 无论如何，您都可以这样做，这样Python代码就可以保持可读性和纯粹性，而不受性能问题的束缚。在

Answer 2

一般来说，您应该优先考虑代码的易读性而不是效率，但是如果您已经证明代码的性能导致了问题，那么（and only then）应该开始优化。在

如果您确实需要降低代码的可读性以加快速度，您可以始终使用注释来解释它在做什么（甚至可以在注释中包括代码的可读性更强的版本，以便人们能够跟踪它的工作）。在

但是要小心，通过注释而不是仅仅通过编写清晰的代码来解释代码，其中一个问题是注释可能会过时。如果你修改了代码但不更新评论，那么你的评论就从一个有用的注释变成了一个黄鼠狼脸的骗子，毁了每个人的一天——如果可能的话，尽量避免这样做。在

Answer 3

我讨厌那些认为通过添加更多方法使代码更具可读性的开发人员。在

a = cuberoot4u(x)

是需要我查找函数以了解发生了什么的代码。在

^{pr2}$

如果没有不必要的函数cuberoot4u是非常可读的。在

不要用大小或冗长来衡量可读性。你需要的是

• 清楚预期的结果
• 弄清楚这是如何实现的

使其易于验证，易于调试，不易误用。上面的函数假装它做了一些复杂的事情，但它并不是——这很糟糕。它隐藏了一个类型转换，这也不好。“内联”版本是非常清晰的一个数学运算，然后转换成字符串。在