原文#
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!
翻訳#
美しいものは醜いものよりも良いです。
明示的なものは暗黙的なものよりも良いです。
シンプルなものは複雑なものよりも良いです。
複雑なものは複雑なものよりも良いです。
フラットなものはネストされたものよりも良いです。
疎なものは密なものよりも良いです。
可読性が重要です。
特殊なケースはルールを破るほど特別ではありません。
ただし、実用性は純粋さに勝ります。
エラーは黙って通過すべきではありません。
明示的に抑制されない限り。
曖昧さに直面した場合、推測する誘惑を拒否します。
それを行うための1つの明確で、できれば唯一の明確な方法があるべきです。
ただし、その方法は最初は明らかではないかもしれません、荷蘭人でない限り。
今は決してないよりも良いです。
ただし、決して今すぐにはないことがしばしば良いです。
実装が説明しにくい場合、それは悪い考えです。
実装が説明しやすい場合、それは良い考えかもしれません。
名前空間は素晴らしいアイデアです - もっとやりましょう！
考察#
この原則は、明示的にパッケージを列挙すること、アスタリスクを使用しないこと、予期しない副作用をメソッドに隠さないことなど、さまざまな例を挙げています。また、有名なソフトウェア設計原則である「設定よりも規約」も、慎重に行わないと、規約が実際の業界の慣習ではない場合にこの原則に違反することになります。
この文に関する StackOverflow の質問：必要な複雑さは避けられませんが、複雑であることは受け入れられません。多くのこと、複雑なことを行うことができますが、冗長であってはなりませんし、理解しにくいこともしてはいけません。複雑さは罪ではありませんが、コードはより論理的で組織的である必要があります。要するに、Simple > Complex > Complicated > Chaotic です。（また、これらの内容は Python の文脈に限定されており、Complex と Complicated の定義は異なる文脈では異なる場合があります）
一部の人々は、次のような長い one-liner を書くのが好きです：lambda L: [] if L==[] else qsort([x for x in L[1:] if x< L[0]]) + L[0:1] + qsort([x for x in L[1:] if x>=L[0]]) # 一行流快速排序これは技を披露することができますが、理解するのは難しいです。他の人が理解できないコードはエレガントなコードではありません。
この記事を書く動機の一つは、Readability counts を「可読性計数」と翻訳する人を見たことです。
実際の開発では、catch した後にログを出力して終了するということがよくありますが、これは良い方法でしょうか？それは良くありません。ソフトウェア業界では一般的に、Let it fail という考え方があります。つまり、プロジェクト全体のライフサイクルで早期に問題が明らかになるほど、修正のコストは低くなります。プロジェクトが本番になってからさまざまな奇妙なバグが発生し、ログを長々と調べることになると、手がかりがなくなります。ですので、皆さんには、このような賢さをもうやめるように助言します。
この記事の著者である Tim Peters は、ここでの「荷蘭人」とは Python の作者である Guido van Rossum を指しており、gvanrossum を褒め称えています。「あなたは本当に天才です」という意味です。
PEP 20 全体を貫く中心的な考え方は「あなたのコードは他の人が読むためのものです！」という一文です。この観点から見ると、理解しにくく、メンテナンスが難しいコードは、「高性能」であっても良いコードではありません。しかし、逆に、一目で理解できるロジックだけが良いコードを意味するわけではありません。プログラミングは本当に難しいです。