はじめに
本記事ではプログラミングの本として有名な「リーダブルコード」を読んだので、簡単に概要を紹介する。
前編では1章〜7章までを紹介。
1章 理解しやすいコード
鍵となる考え
コードは理解しやすくなければならない。
コードは他の人が最短時間で理解できるように書かなければならない。
- 優れたコードとは他人が最短時間で理解できるコードである。理解できるとは変更を加えたり、バグを見つけたりできるという意味だ。
- コードは短い方が良い。だが理解するまでの時間を短くする方が大切だ。
- 理解しやすいコードは設計やテストのしやすさにつながることが多い。
2章 名前に情報を埋め込む
鍵となる考え
名前に情報を詰め込む。
気取った言い回しよりも明確で正確な方が良い。
- 明確な単語を選ぶ。
def Getpage(url):
このメソッドはデータベースやインターネットなどどこから取ってくるかわからない。インターネットであれば、DownloadPage()の方が適切。
また、使用する単語の代替案を調べれば、適切な単語を選択できる。
- tmpやretvalなど汎用的な名前を避ける。（それ相当の理由があれば良い。例えばtmpは情報の一時的な保管など）
- 具体的な名前を使って、物事を詳細に説明する。
- 変数名に大切な情報を追加する。（値に単位あれば書くべき。また、危険や注意が必要な部分には喚起する情報を書く）
- 長い名前はなるべく避ける（スコープの大きな変数には長い名前をつける。）
- プロジェクト固有の省略系は使用しない。（新しくチームに入った人が混乱する）
- 不要な単語は捨てる（DoServerLoop()はServerLoop()で良い）
- 名前のフォーマットで情報を伝える（HTMLならclassの区切り文字にはハイフン、idの区切りにはアンダースコアを使用する）
3章 誤解されない名前
鍵となる考え
名前が「他の意味と間違えられることはないか」と考える。
filter("year <= 2011")
このコードはyearが2011以下のものを指すのか、2011以下を除外したものを指すのかわからない。2011以下ならselect()、除外するならexclude()が良い。
- 限界値を含めるときは、minとmaxを使う。
- 範囲を指定するときはfirstとlastを使う。
- 包括/排他的範囲には、beginとendを使う。
4章 美しさ
鍵となる考え
一貫性のあるスタイルは「正しい」スタイルよりも大切だ。
- 複数のコードブロックで同じようなことをしていたら、シルエットも同じようにする。（メソッドをうまく使う）
- コードの「列」を整理すれば、概要が把握しやすくなる。（縦の線をまっすぐにする）
- ある場所でA・B・Cのように並んでいたら他の場所でB・C・Aのように並べてはいけない。順番に意味を持たせ、常にその順番を守る。（後で見たときに、要素があるかどうかわかりやすくなる）
- 空行を使って大きなブロックを論理的な「段落」に分ける。（グループごとに考えを分けられる。後から見たときに、自分の考えている場所が分かりやすくなる）
5章 コメントすべきことを知る
鍵となる考え
コメントの目的は、書き手の意図を読み手に知らせることである。
- コードからすぐにわかることは書かない。
- 酷いコードはコメントで補助するのではなく、コードそのものを修正する。（酷い名前の関数など）
- コードの欠陥はTODO:（後で手をつける）やXXX:(大きな問題がある）などを使って示す。
- コードを読んだ人が悩みそうなところを予想してコメントを書く。
- 読み手が細部にとらわれないように、コードブロックにコメントをつけて概要をまとめる。
6章 コメントは正確で簡潔に
鍵となる考え
コメントは領域に対する情報の比率が高くなければならない。
- 「それ」や「これ」といった代名詞は避ける。
- 関数の動作はできるだけ正確に説明する。
- 入出力の実例をコメントに書くには、値を慎重に選ぶ。
- 多くに意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ。（情報密度が高くなる）
7章 制御フローを読みやすくする
鍵となる考え
条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く。
行数を短くするよりも、他の人が理解するのにかかる時間を短くする。
要約するときはコードを新鮮な目で見る。
- 条件式の引数は左側が調査対象（変化する値）、右側は比較対象（安定した値）にする。
- 条件は否定系よりも肯定系を使う。（例えば unlessや!=はなるべく使わない）
- 単純な条件を先に書く。ifとelseが同じ画面に表示されるので見やすい）
- 関心を引く条件は先に書く。（優劣が衝突する場合は自分で判断する）
- 三項演算子はなるべく使わない。（短くなるが、コードが読みにくくなることが多い）
- ネストは浅くする。（値を早めに返してあげると浅くできる。）
後編に続く（執筆中）