Python

Pythonで美しいコードを書きたいときに覚えていくべき19の心構えとは?

Pythonできれいなコードを書けって言われたけど、どうしていいか全然わからない」なんてこと、ありませんか?

本記事では、「The Zen of Python, by Tim Peters」というPythonの設計原則について説明していきます。

Pythonの「禅」は全部で19個あります。少し大変ですが、ついてきてくださいね。

The Zen of Python

Beautiful is better than ugly.醜いより美しいほうがいい。

プログラミングは実は書く時間より読む時間のほうが長いです。3ヶ月前のコードなんかもう覚えていられません。美しく読みやすいソースコードは、メンテナンスコストを下げ、トータルコストを引き下げることに貢献します。

Explicit is better than implicit.暗示するより明示するほうがいい。

暗黙的に定義されたものは、確かにタイプ行数は少なくなるかもしれませんが、「そこに暗黙的に定義されたものを知っている」前提でコードを書かないと思わぬ事故を引き起こしてしまいます。それだったら最初から明示したほうが良いよね、という教えです。

Simple is better than complex.複雑であるよりは平易であるほうがいい

複雑なコードは書いているときは気持ちいいですが、コードは書くことより読むことのほうが多いのが現実です。複雑なコードと平易なコード、あなたはどちらを読みたいと思いますか?

Complex is better than complicated.それでも、込み入っているよりは複雑であるほうがまし。

込み入って何をしているかわからないコードよりも、複雑であることがわかるコードのほうがいくらかマシです。前項で述べられている通り、Simpleであることがベストなんですけどね。

Flat is better than nested.ネストするよりフラットなもののほうが良い。

強く親子関係をもたせるよりは、対等な関係に保ち、見通しをよくするほうを優先すべきです。

Sparse is better than dense.密集しているよりは隙間があるほうがいい。

これはコードの内容というよりインデントの問題にもなりますが、メソッド定義のあとに一行あけたり、仮引数の間にスペースを入れて読みやすくしましょう。

Readability counts. 読みやすい分量にしよう

他の人が読むことを想定して、コードの量は読めるものを一区切りとするような習慣をつけましょう。何万行もあるような手続きをコードレビューにもっていかないようにしましょう。

Special cases aren’t special enough to break the rules. 特殊であることはルールを破る理由にならない。

「特殊な実装」と自分が思っていても、大抵は標準の範囲に収まるものなのだから、Pythonの規約に則った書き方ができているかどうかは常にチェックすべきです。

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. 何かいいやり方があるはずだ。誰が見ても明らかな、たったひとつのやり方が。

Pythonのコンセプトとして、「一つのことをするのに複数のやり方は好ましくない」というものがあります。「Pythonは誰が書いてもコード一緒になる」と言われる所以です。その一つのベストな実装を探し続けよう、という趣旨です。

Although that way may not be obvious at first unless you’re Dutch. そのやり方はGUIDOしかわからないかもしれない

伝えたいことは「そのコードはあなたしかわからないかもよ」ということです。

標準から外れたコードを書いてしまうと、その人しかメンテナンスできなくなってしまう、そのような事態に陥らないための「禅」です。

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コンソールでも確認することができる!

pythonのインタプリタを立ち上げて

import this

と入力してみてください。今回紹介した文言が表示されるはずです。

まとめ

本記事では、Pythonで重視されている19の原則「Zen of Python」について説明しました。

闇雲にコードを書くよりも、ある程度の指針を示されたほうがこれからの学習効率も上がるのではないでしょうか。