Python 之禅；深入解读

Tim Peters 的《Python 之禅》为 Python 代码的编写提供了指导原则。你的代码不必完全遵循这些指导原则，但最好牢记在心。

>>> import this
"""The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one -- and preferably only one -- obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!"""

美丽胜过丑陋

我相信这已经不言自明了，但我还是要再说一遍。它只是说，优美的代码胜过丑陋的代码。编写一个一读就懂的程序，比编写一个需要读者花些时间去理解的程序要好。当然，并非每个脚本都需要优美，而且优美本身就是主观的，但 Python 的流行很大程度上就源于其易用性。

# code 1

file = "lyrics.txt"
open("disordered.txt", "w").write("\n".join(map(lambda x: x[::-1], open(file, "r").read().split("\n")[::-1])))

# code 2

file = "lyrics.txt"
# first read the input file
lyrics = open(file, "r").read()

# split the lyrics into lines and reorder it in reverse form
lyrics = lyrics.split("\n")[::-1]

# reverse each line in the lyrics
reverse = lambda x: x[::-1]
lyrics = list(map(reverse, lyrics))

# merge the new lyrics together
lyrics = "\n".join(lyrics)

# save the file
open("disordered.txt", "w").write(lyrics)

您更喜欢以下哪一个代码并且觉得哪一个代码容易理解？

明确优于隐含

这意味着你应该避免将代码功能隐藏在晦涩难懂的语言特性背后，因为这些特性需要熟悉才能完全理解。让你的代码即使对你或你的程序一无所知的陌生人也能轻松阅读。参考上面的代码

简单胜于复杂

这告诉我们，构建任何东西，都可以用简单的技术来完成。遇到简单的问题，就用简单的方案解决；遇到复杂的问题，就把它分解成更简单的部分，然后用简单的方案解决。

复杂胜过复杂

回到之前的规则，有些问题没有简单的解决方案，在这种情况下，你必须使用复杂的答案。但这总比使用复杂的答案要好。选择简单而不是复杂，但要知道简单的限度。

扁平优于嵌套

程序员喜欢将事物组织成类别，尤其是包含子类别的类别，而子类别又包含其他子类别。将代码放在一个顶层模块或类中是可以的，而不必分散到多个子模块或子类中。假设你创建的包和模块需要类似这样的代码import spam.eggs.bacon.ham.foo.bar，那么你的代码就太复杂了。

稀疏优于密集

这又回到了上面的代码示例。作为程序员，我们可能希望用一行代码实现很多功能。然而，将代码分散到多行代码中总比用一行代码完成所有工作要好。

可读性很重要

这意味着你的代码应该易于阅读，而不是使用单字母变量或不缩进（尽管 Python 强制这样做）。使用你和其他开发人员容易阅读和理解的代码。记住，代码被阅读的次数比被编写的次数多。

特殊情况不足以打破规则

编程中充满了程序员应该在代码中努力践行的最佳实践。为了快速修改代码而绕过这些最佳实践可能很诱人，但最终可能会导致代码变得混乱不堪，不一致且难以阅读。

虽然实用性比纯粹性更重要

在某些情况下，您可能需要对上述规则做出例外。过度遵循规则可能会导致代码高度抽象且难以理解。随着经验的积累，在两条规则之间游走会变得更容易。随着时间的推移，您不仅会学习规则，还会了解何时打破规则。

错误不应该默默地传递

永远不要让发生的错误让读者感到困惑。你可以在错误发生时打印一个字符串来快速解决这个问题。程序员经常忽略错误消息并不意味着程序应该停止发出它们。

除非明确禁止

你可以选择忽略程序明确导致的错误。但务必确保你是有意识地这样做，并且明确说明原因。

面对歧义，拒绝猜测

如果你的代码无法正常工作，那肯定是有原因的，只有谨慎、批判性地思考才能解决问题。不要盲目尝试解决方案，除非它看起来有效；通常情况下，你只是掩盖了问题，而不是解决了它。

应该有一个——最好只有一个——明显的方法来做到这一点

事实证明，用三四种不同的方式编写完成相同功能的代码是一把双刃剑：虽然你可以灵活地编写代码，但为了读懂它，你必须学习所有可能的编写方式。这种灵活性不值得你花费三倍甚至四倍的精力去学习一门编程语言。

尽管这种方式一开始可能并不明显，除非你是荷兰人

这句话纯属玩笑。Python 之父 Guido van Rossum 是荷兰人。学习或回忆 Python 规则对他来说通常比​​其他人都容易。

现在总比没有好

这告诉我们，我们不应该花太多时间进行规划和预先优化；先找到能完成工作的东西，然后不断迭代。不要拖延，不要推迟不可避免的事情。

尽管永远都比现在更好

这指的是之前的规则，我们应该认真思考我们所做的事情，这样你就不会走上一条以后无法优雅回头的道路。

如果实施起来难以解释，那就不是一个好主意

这告诉我们，如果实施起来很复杂，那么它就不简单，这意味着它远不是最终草案，这意味着它不适合作为最终草案提出。

如果实现起来很容易解释，这可能是一个好主意

这两条规则提醒我们，如果高性能代码复杂到程序员无法理解和调试，那么它就是破坏性代码。但是，仅仅因为程序代码很容易向别人解释，并不意味着它不是破坏性代码。

命名空间是一个非常棒的主意——让我们多做一些这样的事情吧！

命名空间（以及全局和局部作用域）对于防止一个模块或作用域中的名称与另一个模块或作用域中的名称冲突至关重要。但也要记住，扁平优于嵌套：命名空间虽然很棒，但其用途应该仅限于防止命名冲突，而不是增加不必要的分类。