リーダブルコードの要約のメモ（後半）

このメモは「リーダブルコード」を読んだ際のものです。 自分用のメモなので、本の構成の順番を守っておらず、例も本のものではなく自分の理解で置き換えたものになっているので注意してください。

大原則: 優れたコード = 人が最短の時間で理解できるコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

前半

paper.hatenadiary.jp

ロジックの構造化

6. 制御フローを見やすく

• コードの並び順と書き方を明確に
  • 比較：左辺を調査対象、右辺を比較対象
  • if/else: 否定の比較を使わない、重要な条件を先に
  • 三項演算子: 単純な二変数の比較・代入以外で無理に使わない、理解のしやすさが最優先
• do-while文を避ける
  • continueのわかりにくさ
  • 条件（重要な箇所）を先に記述する
• return
  • 理解しやすさが優先
  • returnを関数末端に持ってくるためだけにコードを複雑にしてはいけない
• go-to文を避ける
• ネストをむやみに深くしない

7. 巨大な式を分割する

• 説明変数と要約変数を作る
  • 変数に何の値が入っているか、それが何を示しているかの見やすさが優先
  • 逆に、複雑な式を分割したり変数に含まれる値を要約できていない変数は削除するべき（次の章）
• ドモルガンの法則を使う
  • not(!)が一番外側の括弧についていると条件が分かりにくくなる
  • 条件分岐のわかりにくさはエラーや取りこぼしの原因になる
  • 短絡評価の悪用
    • 範囲指定の条件や複雑な入れ子など場合分けが複雑な条件分岐を避ける
    • 複雑になる場合は”反対”（例：[1, 2] の範囲の反対は 1),(2 を一旦考えてみる）

この後長い処理をマクロでまとめるなどの例が出てくるが、総じて複雑な条件分岐のパターンを見やすくすることでバグや見落としを回避する。

8. 変数と読みやすさ

• 余分・不要なコードの削除
  • 手前の章にあるような、複雑な式の要約や分割を行わない変数
  • 中間結果を一時的に持つ変数の削除したい
  • 制御フローのための変数を削除する
    • complete_vgg16_train = False などの変数を用意して分岐を制御する変数
    • 制御の入れ子が重なる場合は他の関数として切り出す
• 変数のスコープを少なくする
  • 大域変数を使用しない
  • スコープ内部だけでしか使用しない変数を用意
  • 変数宣言の位置を下げる
    • 使用する直前で宣言をする
  • 変数は一度だけしか代入されないようにする
    • const等を使える場所でしっかり宣言する

コードの再構成

9.無関係の下位問題を抽出する

• 下位問題の抽出
  • コードブロックごとの高レベルでの目的は何かを定める
  • コードブロック内部で、高レベルの問題とは関係ない↓位問題をどれくらい含んでいるかを俯瞰して
  • 無関係な問題を解決するためのコードが多数含まれる場合はその箇所をくくりだす
• 汎用コードを作る
  • プリントのフォーマット化など、高レベルでの目的にならないがどこでも利用できるコードは関数としてくくりだす
  • 入力と出力がはっきりしていればデバッグもテストも楽になる
• 簡潔なインターフェースを作る
  • 複雑な処理は外部に切り出し、ラッパー関数を作る
  • 例: 指定したウェブページの <article>...</article>部分の文字列だけを抽出する
    • get_article_str(http_adress)などとして内部に細かいテキストのフィルタリングを記述する

10. 一度に一つの事を実行する

• 複数のタスクを並列で実行しない
  • 一つのコードブロックで一つのタスク
  • ”デフラグ”されているタスクを直列にまとめる

11.〜

省略。