お盆休みを使って、今更ながら
リーダブルコード
を読了しました🐜
この記事では、わたしの感想と自分にとって大事なポイントをまとめます。
感想
コーディングの際に気をつけておきたいポイントがまとめられており、業務がソフトウェア開発（プログラミング）である方を対象とした書籍でした。
したがって、上流工程やプログラミング初心者にはちょっと向かないと思います。
内容は、終始やわらかい文面で、掲載されているコード例も簡単なものなので、とても読みやすいです。
コード例は、C++やPython, JavaScriptで書かれていますが、内容はこれらのプログラミング言語に限定されません。
種類に関わらず、プログラミング言語を1つでも使われている方なら、誰でも読むことができます。
複数人で開発をする際、たいていチームで守るべきコーディング規約があるかと思います。本書では、コーディング規約よりも抽象度の高い概念を扱っています。
例えば、わかりにくい箇所ではコメントをしっかり書くとか、できるだけ共通化して関数を小さくするとかなど、人によってはかなり基本的なことが書かれています。
このように広い内容を扱っているため、コーディング規約では規定できないグレーな領域で、「こんな考え方するとスッキリと書けるよ」というようなことがたくさん書いてあります。
よって、もし今開発しているソースコードに対して、なにかモヤモヤと感じているのであれば、本書はかなりオススメです。
私は仕事でプログラミングするようになって、7年ほど経ちましたが、意外と見落としていた観点が書かれていました。この本を読んで、良い気づきが得られて、とても勉強になりました。
今後は、たまに読み返してコーディングの考えを整理する、というような使い方をすると思います。
リーダブルコードメモ
備忘録として、私のメモを以下に整理します。
優れたコードとは？
とにかく、他人が理解しやすいコードが優れたコードである。「理解しやすい」とは、他人がコードを理解するための時間が最短であること。「他人」とは、詳細を忘れた作成者である自分も含む。
優れたコードを書くために、コードはできるだけ短く、または小さくすることを心がけるべき。
しかし、それ以上に理解するまでにかかる時間を短くすることを優先すること。
命名のコツ
関数名は接頭語を動詞にするのが一般的であるが、getやstopは抽象度が高く、もっと具体的な動詞が良い。
例えばgetPage()だと、どこからデータを取ってくるのかがわからない。もしインターネットから取ってくるのであれば、fetchPage()やdownloadPage()などが適している。
stop()であれば、より動作に合った動詞を選択したい。取り消しができない操作であればkill()だとか、あとから再開できるのであればresume()やpause()などが適している。
単位を持つ変数であれば、単位を含んだ変数名にすると良い。また、文字コードやエンコード・デコードなど重要な属性を持つ変数であれば、同様にそれを含んだ変数名にする良い。
ただし、スコープが小さい場合は、短い変数名にしてもよい。なぜなら、スコープが短ければ、その変数を追う領域は小さいため、理解の妨げにならないし、むしろコードがスッキリして理解しやすい。
原則、具体的に命名すれば、その分だけコメント文を短くしても、優れたコードを保持できる。
命名に迷ったら、例えば以下のサイトを参考にしてみる。
英辞郎 on the WEB Pro Lite
例文が豊富で、英語論文書くときに当時の指導教官に教えてもらいました。weblioでも良いけど、こっちが好き。codic
説明不要だと思いますが、日本語を入れるとそれっぽい変数名や関数名を教えてくれます。ABBREVIATIONS
変数名を短くするために使う略語を調べるときに使います。検索ボックスの右にあるラジオボタン「Term>>Abbreviation」をクリックして使うこと。Google検索で「hoge abbreviation」で検索しても良い。
誤解されない名前の例
最大値または最小値を意味する変数にはmaxまたはminを変数名に含むと良い。（私の場合はこれとは別に、上限値または下限値を意味する変数にはul(upper limit)またはll(lower limit）を含んだ変数名にします）
の範囲を表したいときは、firstとlastを変数名に含む。
の範囲を表したいときは、beginとendを変数名に含む。
bool値の変数名には、以下のような接頭語をつけると良い。
| 接頭語+品詞 | 意味 |
|---|---|
| is+形容詞 | 形容詞の状態であるかどうか |
| has+過去分詞 | 過去分詞が完了したかどうか |
| can+動詞原型 | 動詞原型の動作ができるかどうか |
| should+動詞原型 | 動詞原型の動作をすべきかどうか |
コメントのコツ
他人が理解できる時間が短くなるよう、コメントを入れる。少なすぎても、多すぎてもダメ。
コメントに自分の考えを記録しておくのも重要である。
例えば、現状のコードに欠陥がある場合は、以下のような記法で記録しておく
| 記法 | 意味 |
|---|---|
| TODO: | あとで手をつける 小さな問題であれば todo: と書いたりする |
| FIXME: | 既知のバグがあるコード |
| HACK: | あまりキレイでない解決策 |
| XXX: | 危険で大きな問題がある |
他にも、定数であれば、その値になった背景や理由を書いておくと良い。
標準ライブラリ
コードを簡潔にするために、プログラミング言語にすでに用意されている標準ライブラリを、空いた時間などで確認しておく。 例として、以下に標準ライブラリをリンクを載せておく1。
The Zen of Python
リーダブルコードとは関係ありませんが、最後に有名な The Zen of Python を写経します。
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. それを明確にする方法は1つ、優れた方法がたった1つあるはずだ。 Although that way may not be obvious at first unless you're Dutch. しかし、あなたがオランダ人でもない限り、その方法は一見わかりにくいかもしれない。 （Python開発者のGuido van Rossumがオランダ人であることに由来する） 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つであり、どんどん使うべきだ。
なお、以下のリンクを参考に、私なりの日本語訳をつけました。
おわりに
リーダブルコードを読んで、個人的なまとめをしてみました。噂通りの良書で、買ってよかったです！
参考になれば幸いです(^^)
-
いま使ってるのはPythonくらいしかない。↩
