The Invent with Python Blog

Tim PetersによるThe Zen of Pythonは、Python言語の設計のための20のガイドラインです。 あなたのPythonコードは必ずしもこれらのガイドラインに従う必要はありませんが、心に留めておくのが良いです。 Pythonの禅は、あなたが実行した場合に表示されるイースターエッグ、または隠された冗談ですimport this:

>>> import thisThe Zen of Python, by Tim PetersBeautiful 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!

注：不思議なことに、ガイドラインの19だけが書き留められています。 Guido van Rosumは、20番目の格言が欠落していると伝えられています”いくつかの奇妙なティム-ピーターズの冗談です。「

最終的には、これらのガイドラインは、賛成または反対する意見である。 道徳的なコードのすべての良いセットのように、彼らは時々最も柔軟性を提供するために自分自身と矛盾します。 これらの格言の私自身の解釈は次のとおりです：

美しいことは醜いことよりも優れています。

プログラマは、読みやすさを気にせずにコードを素早く書くことがよくあります。 コードは読みやすくする必要はありませんが、Python言語自体のコードは考え抜かれ、一貫性があり、使用する喜びでなければなりません。 もちろん、すべてのスクリプトが美しくなければならないわけではなく、美しさは主観的ですが、Pythonの人気の多くは、作業がとても簡単であることの結

Explicitはimplicitよりも優れています。

「この格言は自明だ」それはどんな格言に対しても恐ろしい説明になるだろう。 同様に、コードは冗長で明示的である方が良いでしょう。 完全に理解するために精通している必要があるあいまいな言語機能の背後にコードの機能を隠すことは避けてください。

シンプルは複雑よりも優れています。 複雑さは複雑さよりも優れています。

この二つの格言は、何でも構築することは単純または複雑な技術を使って行うことができることを思い出させます。 巣箱を建てるなどの単純な問題では、簡単な解決策が優れています。 一方、ディーゼル機関を構築することは、複雑な技術を必要とする複雑な問題です。 技術的に鳥小屋の技術を使用してディーゼル列車エンジンを作ることができてもおそらく理想的な解決でない鳥小屋の部品の複雑な、Rube Goldbergの整理で終 複雑さよりも単純さを好むが、単純さの限界を知っている。

フラットはネストよりも優れています。

プログラマは、物事をカテゴリ、特に他のサブサブカテゴリを含むサブカテゴリを含むカテゴリに整理するのが大好きです。 これらの階層は、官僚主義を追加するほど組織を追加しないことがよくあります。 複数のサブモジュールまたはサブクラスに分割するのではなく、1つの最上位モジュールまたはクラスにコードを配置しても問題ありません。 import spam.eggs.bacon.ham.foo.barのようなコードを必要とするパッケージやモジュールを作成すると、コードが複雑になりすぎます。

スパースは密よりも優れています。

プログラマは、次のようなワンライナーのように、できるだけ少ないコードに多くの機能を詰め込むことを好むことがよくあります: print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 . While code like this may impress their friends, it'll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.

可読性のカウント。

strcmp()は明らかに1970年代からCでプログラミングしてきた人と”文字列比較”関数を意味するかもしれませんが、現代のコンピュータは完全な関数名を書き出すのに十分なメモリを持っています。 あなたの名前から母音を落としたり、過度に簡潔なコードを書いたりしないでください。 コードは書かれたコードよりも頻繁に読み込まれるため、簡潔で文書化されていないコードよりも明示的で読みやすいコードの方が重要です。

特殊なケースは、ルールを破るほど特別ではありません。 実用性は純度を打つが。

これら二つの格言は、集合として来て、互いに矛盾する。 プログラミングは、プログラマが自分のコードで努力すべき”ベストプラクティス”に満ちています。 迅速なハックのためにこれらの慣行を幅木することは魅力的かもしれませんが、矛盾した、読めないコードのラットの巣につながる可能性があります。 しかし、ルールに従うために後方に曲がると、非常に抽象的で読めないコードになる可能性があります。 すべてのコードをオブジェクト指向のパラダイムに適合させようとするJavaプログラミング言語の試みは、多くの場合、最小のプログラムであっても これらの2つの格言の間の線を歩くことは、経験によってより簡単になります。 そして、時間内に、あなたはルールを学ぶだけでなく、それらを破るときにも学びます。

エラーは黙って渡すべきではありません。 明示的に沈黙しない限り。

プログラマがエラーメッセージを無視することが多いからといって、プログラムがエラーメッセージの出力を停止すべきではないという意味ではありません。 サイレントエラーは、関数が例外を発生させる代わりにエラーコードまたはNoneを返すときに発生する可能性があります。 これらの2つの格言は、エラーを沈黙させてプログラムを実行し続けるよりも、プログラムをfail fastしてクラッシュさせる方が良いことを教えてくれます。 後で必然的に発生するバグは、元の原因から遠く離れているため、デバッグが困難になります。 プログラムが引き起こすエラーを明示的に無視することはいつでも選択できますが、そうすることを意識的に選択していることを確認してくださ

曖昧さに直面して、推測する誘惑を拒否する。

コンピュータは人間を迷信的にしました：私たちのコンピュータ内の悪魔を祓うために、私たちはそれらをオフにしてからオンにする神聖な儀式を行 おそらく、これは神秘的な問題を解決します。 しかし、コンピュータは魔法ではありません。 あなたのコードが機能していない場合は、理由があり、慎重で批判的な思考だけがそれを解決します。 何かが動作するように見えるまで盲目的に解決策を試してみる誘惑を拒否します。

それを行うには、一つの、そして好ましくは一つだけの明白な方法があるはずです。

これはPerlプログラミング言語のモットー、”それを行うには複数の方法があります！”同じことを行うコードを書くための三つまたは四つの異なる方法を持つことは両刃の剣であることが判明しました：あなたはコードを書く方法に柔軟性 この柔軟性は、プログラミング言語を学ぶために必要な3倍または4倍の努力の価値はありません。

あなたがオランダ人でない限り、その方法は最初は明らかではないかもしれませんが。

このセリフは冗談です。 グイド-ファン-ロッサム、Pythonの作成者とBDFL（人生のための慈悲深い独裁者）は、オランダ人です。 しかし、この格言でさえ、Pythonが文字列を書式設定する3つの異なる方法を組み込むことを妨げていませんでした。

今は決してよりも優れています。 決して多くの場合、*右*今よりも優れていませんが。

これらの二つの格言は、無限ループにハングアップしたり巻き込まれたりするコードは、そうでないコードよりも明らかに悪いことを教えてくれます。しかし、誤った結果を出して早く終了させるよりも、プログラムが終了するのを待つ方がほぼ確実に良いです。

実装を説明するのが難しい場合、それは悪い考えです。 実装が説明しやすい場合は、良い考えかもしれません。

Pythonは、プログラムがより速く実行されるように、コンピュータを収容するのではなく、プログラマの仕事を容易にするために努力しています。 そして、プログラムは、それを書いたプログラマだけでなく、コードを維持する他のプログラマによっても理解できる必要があります。 これらの2つの格言は、「高性能」コードが非常に複雑で、プログラマが理解してデバッグすることが不可能な場合、それは悪いコードであることを思い出させ しかし、悲しいかな、プログラムのコードを他の人に説明するのは簡単だからといって、それが悪いコードではないという意味ではありません。 プログラミングは難しいです。

名前空間は素晴らしいアイデアの一つです—それらの多くをやってみましょう！

名前空間(およびグローバルスコープとローカルスコープ)は、あるモジュールまたはスコープ内の名前が別のモジュールまたはスコープ内の名前と競合しないよ しかし、flatはネストされたものよりも優れていることを覚えておいてください：名前空間は、名前の競合を防ぎ、不必要な分類を追加しないためにのみ作

プログラミングに関するすべての意見と同様に、私がここに書いたものは、あなたの状況に反対するか、単に無関係である可能性があります。 コードをどのように記述すべきかを議論することは、あなたが考えるほど生産的ではありません。 （プログラミングの意見の完全な全体の本を書いていない限り。)