Python 之禪 (知乎上目前最好的翻譯版本)

來自專欄不想當翻譯家的吃貨不是好碼農1 人贊了文章PEP 20 -- The Zen of Python?

www.python.org

原文

PEP 20 -- The Zen of Python

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 arent 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 youre Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, its a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- lets do more of those!

翻譯

美 優於 丑

明確 優於 隱晦 （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

推薦閱讀：