[読書メモ] リーダブルコード

概要

この記事は、私が「リーダブルコード --より良いコードを書くためのシンプルで実践的なテクニック」を読んだ際に理解したこと・大事だと思ったことを箇条書きでまとめています。
少しでも気になる部分があれば実際に本を読んでみることをお勧めします。

第I部　表面上の改善

第1章　理解しやすいコード

• 良いコードとは、「理解にかかる時間が最も少ないコード」である

第2章　名前に情報を詰め込む・第３章　誤解されない名前

• 良い名前とは「その命名対象の振る舞いが一意に伝わる名前」である
• 一意に振る舞いを表現する方法として
  • 複数の意味を持つ単語（ex. get）ではなく、明確に意図が伝わる単語（ex. fetch）を使う
  • 抽象的な命名は避け、より具体的な命名をする
  • 汎用的な名前は避ける（ex. tmp）
  • 接頭辞や接尾辞を追加して表現（ex. ポインタなら接頭辞にpを付ける、ミリ秒を表す時間なら_msをつける）
• 誤解されない名前にする方法として
  • ユーザーの期待に合わせる（ex. getなら軽量な取得処理を期待）
  • 複数の名前を検討する
  • 最大最小にはmax, minをつかう
  • 範囲指定にはfirst, lastをつかう
  • 包含と排他的範囲にはbegin, end（endが包含が排他か曖昧だが、begin, endのイディオムとして一般的に排他。）

第4章　美しさ

• 美しいコードは可読性を高め、ミスを減らす
• 美しいコードにするために
  • 似ている処理はまとめ、異なる処理とは段落わけし、似る・異なることを視覚的にわかるようにする
  • 一貫性を持たせる（入力の引数と同じ順番で処理するなど）

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

• コメントすべきではないこと
  • コードを読んだらすぐにわかること
  • 粗悪なコードの挙動に関する補足コメント（コードを修正しよう）
• コメントすべきこと
  • そのコード・変数の値に至った背景や考え方
  • 注意する点
  • コメントで読んだ方が理解が早い

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

• エッジケースの例を書く
• 記号を使っても良い
• 情報密度の高い言葉を使おう
• 関数の挙動は正確に
  • ex. 行数を数える→改行を数える

第II部　ループとロジックの単純化

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

• 条件文は左側に比較したい変数、右側に値の安定した変数を置く
• ネストはガード節・早期リターンで解消

第8章　巨大な式を分割する

• 巨大な式は理解しやすい大きさまで分割する

• 条件文はドモルガンの法則を使って細かい条件の結合に変換する

  # before
  if !(a or b or c):
  	...
  # after
  if !a and !b and !c:
  	...
  

• 意味の分かりにくい式の値を適切な変数に格納する

  # before
  if line.split(':')[0].strop() == "root":
  	...
  
  # after
  username = line.split(':')[0].strop()
  if username == "root":
  	...
  

第9章　変数と読みやすさ

• 変数は少なく、変数のスコープは短く

• 変数は不変にする

• 制御変数に注意。制御変数は多くの場合使わずにかける

  is_done = False
  while (!is_done):
  	if a is True:
  		is_done = True
  

第Ⅲ部　コードの再構成

第10章　無関係の下位問題を抽出する

• その関数の目的を達成するために必要な処理のうち、目的と直接的に関係しない処理は関数として抽出する

第11章　一度に一つのことを

• 一度に一つのタスクのみ行う

第12章　コードに想いを込める

• 誰でも理解できる簡単な言葉で解説できるようにする
  • 可読性の向上
  • 下位問題の抽出がしやすくなる

第13章　短いコードを書く

• コードは短く書いた方が良い
  • コードが長いと理解コスト・保守コストがかかる
• コードを短く保つ方法として
  • 解くべき問題からサブ問題を抽出
  • 不要な機能の実装をしない
  • ライブラリがあるならそれを使う
  • できる限り簡単な解法を探す

第Ⅳ章　選抜テーマ

第14章　テストと読みやすさ

• テストは非公式な仕様書
• テストは
  • 何をテストしているか分かりやすく
    • 関数名を適切に
    • テストケースはわかりやすいものを
    • 仕様的にエッジケースな部分を含める
  • assert文はテストライブラリのものを使用する
    • 出力内容が豊富
  • テストのしやすいコードは良いコードである
    • 内部の状態を持たない
    • 適度に疎結合