Python——代码书写风格

Python之禅

Tim Peters的“Python之禅”汇集了Python语言涉及和Python编程20条准则。

它是个复活节彩蛋，或者说是隐藏的笑话。当运行import this时就会出现。

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之所以受欢迎，是因为它的语法不想其他语言那样充斥着神秘的标点符号。

• 明确胜于隐含

代码应该是详细明确的，应避免把代码的功能隐匿再晦涩的、且需要对语言非常熟悉才能理解的语言特性中。

• 简单胜于复杂。复杂胜于更复杂。

任何东西都既可以用简单的技术建造，也可以用复杂的技术建造。一个用铲子就能解决的小问题，没必要用挖掘机来搞。而如果是大工程，那么调用挖掘机来作业，总是比拿100个铲子来的要直接一些。所以，要学则简单而非复杂，但也要知道简单方案的局限性。

• 扁平胜于嵌套

别嵌套那么多的子类别，这些层级结构往往并不会增强代码的组织性，而是增强了官僚性。

• 稀疏胜于密集

不要让代码一次做太多的事情。分散再多行的代码往往比密集的单行代码更容易阅读。即简单胜于复杂

• 可读性很重要

缩写名称很容易，但是给人的理解会很烦恼。现在的内存信息足以让你编写完整的函数名称。所以花点时间为变量和函数想出具有描述性且具体的名称。

• 特殊情况不足以打破规则，尽管实用胜过纯粹

在编程过程中，有很多最佳实践值得程序员努力践行。一方面，绕过这些实践，快速实现需求也许会很好，但可能会导致一堆不一致、不可读的代码烂摊子。另一方面，妥协遵守一些规则可能会导致高度抽象、不可读的代码。

• 错误永远不应该悄无声息地过去，除非明确沉默。

当函数返回错误代码或None而不是提示异常时，“无声的错误”就会发生。即程序快速失败和崩溃要比不提示错误并继续运行好。后来发生的不可避免的错误将更加难以调试。

• 面对模棱两可的问题，不要猜测

代码未能正常执行时有明确原因的，只有通过仔细、批判性的思考才能解决问题。拒绝通过盲目尝试来解决问题。

• 应该有一个，最好只有一个明显的方法能使用

事实证明，多种方法，好处可以灵活使用多种写法，坏处是需要学习和了解多种写法。最好只有一个明显的方法能使用。

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

笑话而已，创造者Guido van Rossum 是荷兰人。

• 有总比没有好，然而不经思考就做还不如不做

运行速度慢的代码显然比不上运行速度快的代码。但是，多等待程序运行一会儿，总比程序尽快运行完却发现结果是错的要好。

• 如果实现很难解释，那就是个坏主意。如果实现很容易解释，那可能是个好主意。

如果代码复杂到让专业人员无法理解和调试的程度，那就是坏代码。但是，很容易被解释的代码也不一定就是好代码。

• 名称空间是一个非常棒的想法——让我们做更多这样的事情吧！

扁平胜于嵌套，尽管命名空间确实很好，但你应该只为防止命名冲突而使用命名空间，而不是添加不必要的分类。