The Zen of Python

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

PEP 20 -- The Zen of Python | Python.org https://www.python.org/dev/peps/pep-0020/

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之禅 - 知乎 https://zhuanlan.zhihu.com/p/35744303

Python 之禅 (知乎上目前最好的翻译版本) - 知乎 https://zhuanlan.zhihu.com/p/40950546

翻译

美 优于 丑

明确 优于 隐晦 （1）

简单 优于 复杂

复杂 也好过 繁复 （2）

扁平 优于 嵌套

稀疏 优于 拥挤

可读性很重要（3）

固然代码实用与否 比洁癖更重要，

我们以为的特例也往往没有特殊到必须打破上述规则的程度

除非刻意地静默，

否则不要无故忽视异常（4）

如果遇到模棱两可的逻辑，请不要自作聪明地瞎猜。

应该提供一种，且最好只提供一种，一目了然的解决方案

当然这是没法一蹴而就的，除非你是荷兰人（5）

固然，立刻着手 好过 永远不做。

然而，永远不做 也好过 不审慎思考一撸袖子就莽着干

如果你的实现很难解释，它就一定不是个好主意

即使你的实现简单到爆，它也有可能是个好办法

命名空间大法好，不搞不是地球人！

 

注释

1. 该引入的包一个一个列出来不要合并；不要用星号；不要在方法里藏意想不到的的副作用，等等等等。还一个例子，另外一种著名的软件设计原则 Convention over Configuration（约定优于配置）如果做得不谨慎就会违背这条
2. SO: 必要的复杂逻辑是难免的，而繁复啰嗦的代码是不可接受的
3. Readability counts 不能翻译成可读性计数啊喂
4. 实操中很多人不注意 catch 完就 log 一下 就不管了，这样不好。软件界一般都讲 Let it fail，学名为 Fail-fast 法则。简而言之就是整个项目周期中越早暴露的问题，其修复成本越低
5. 本文作者 Tim peters 解释说这里的荷兰人指的是 Python 的作者 Guido van Rossum

Beautiful is better than ugly.

美比丑好。

Explicit is better than implicit.

要说清楚。

Simple is better than complex.

简单比复杂好

Complex is better than complicated.

复杂比凌乱好。

这个必须要上例子：

What does "Complex is better than complicated" mean?

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.

实践是唯一的真理。这句话似乎在点名批评Haskell。

很奇怪，网上的中文翻译版似乎很喜欢漏掉这一句。

Errors should never pass silently.

不要忽略错误。

Unless explicitly silenced.

除非你显式指定。

这两句看似矛盾。解释一下，我们用PHP来举例：

$a=$_GET['a']; // 错误，可能是未定义
$a=@$_GET['a']; // 可以，说明你知道a可能未定义
$a=@$_GET[$name]; // 错误，$name同样可能未定义，那么你到底忽略的是哪个错误呢？

In the face of ambiguity, refuse the temptation to guess.

拒绝歧义。

There should be one-- and preferably only one --obvious way to do it.

我来讲个笑话：python3

现在看来，对这个做的最好的是：Go语言。

Although that way may not be obvious at first unless you're Dutch.

Python的创造者是荷兰人。他以自己的喜好创建了Python，所以，荷兰人应该觉得这门语言挺直观的。

这个冷笑话不好笑。

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!

其他所有的都是哲学，只有这一条是实践。可见受C语言荼毒很深呀。