リーダブルコードのまとめ。 1/2

リーダブルコードを読み終わったので、内容をまとめます。

【第一部-表面上の改善】

2章-名前に情報を詰め込む

• 変数名には、その目的が分かるような明確な単語を選ぶ。例えば、get~という変数をもっと具体的に、fetch~やdownload~とする。
• tmpやnumなどの汎用的な名前はできるだけ避ける。
• メソッド名やクラス名は短いコメントのようなものである。このクラスやメソッドは何をするクラスなのか、一目でわかるような名前にする。
• 変数名に大切な情報を追加する。例えば、ミリ秒を表す変数名には _msをつける。
• 変数名のスコープが大きい場合、長い名前を付ける。1単語や2単語だと、その変数が何を表しているのかとても分かりづらくなってしまう。
• ローカル変数とグローバル変数を区別できるよう、変数に印をつける。例えば、グローバル変数には一番最初に_(アンダーバー)をつけるなど。

3章-誤解されない名前

• 意図が伝わるような名前を選ぶ。例えば、filterという名前は「選択する」という意味にも解釈できるし、「除外する」という意味にもとれる。「選択する」であればselectを、「除外する」であればexcludeにするのがよい。
• 上下の限界値を決めるときはmax_やmin_を前につけるとよい。ブール値ならisやhasを前につけ、包含的範囲であればfirstやlastを使うとよい。
• get()やsize()は軽量メソッドの時に使うことが期待されている。

4章-美しさ

• 複数のコードブロックで同じような処理があったなら、その処理のコードのシルエット(見た目)は同じようにする。
• インデントを使い、縦の列をそろえる。
• 処理の順番がある場所でA,B,Cの順番で並んでいたならば、他の場所でB,C,Aのように並べるのは良くない。最初にどのような順番にするかを決め、一貫してその順番を守る。
• コードの中で、処理や似ている考えごとに空行を使って段落に分ける。

5章-コメントすべきことを知る

• コメントすべきでは「ない」こと・・・コードを見ればすぐに分かってしまうようなことはコメントすべきでない。また、汚いコードがどのような処理をしているかを補助的にコメントするのも良くない。補助的なコメントを書くのではなく、コードそのものを修正する。

• 自分の考えを記録する・・・定数がなぜその値を持っているのか、何を行うのかという「背景」を記録する。なぜほかの方法ではなくそのような処理の書き方にしたのかという「背景」を記録する。

• コードの欠陥をTodoやXXXなどをつけて示す。
  TODO⇒あとで手を付ける
  FIXME⇒既知の不具合があるコード
  HACK⇒あまり綺麗じゃない解決策
  XXX⇒大きな問題がある

• コードやクラスの全体像を書く。クラスはどのように連携しているのか、データはどのように流れるのか、等を記録する。

• 平均的な読み手が迷うような処理は予想して文書化しておく。

• 読み手が細部にとらわれないように、コードブロックにコメントをつけて概要をまとめる。

6章-コメントは正確で簡潔に

• コメントは簡潔に！長々と書かないようにする。
• 入出力の処理のコメントには実例をつける。例えば、入力[5,4] 出力[9,2]など。
• よくわからない引数にはインラインコメントを使う。
  インラインコメントは、関数の呼び出し時、引数の横にコメントをつける手法である。例えば、
  Connect(/timeout_ms=/ 10, /use_encription=/ false); など。
• 低レベルの詳細ではなく、高レベルの処理内容を書く。
  関数の中の「計算の内容」の説明をするのではなく、その関数は「何を行うのか」を説明する。

【ループとロジックの単純化】

7章-制御フローを読みやすくする

• 比較 if(a < b)等を書くときは、変化する値を左に、より安定した値を右に配置する。
• if/else文のブロックは適切に並び替える。肯定系、目立つもの、単純なものを先に処理する。
• 三項演算子(? :)やdo-whileループを単純な処理以外に使用する場合、コードが読みにくくなる場合が多いので使わない方がよい。
• 深いネストを避ける。分離できそうな処理は先にreturnして処理を終わらせておく。直線的なコードを書く。

今回は以上です。後半は次回で書きます。