「リーダブルコード」の目次

次の書籍を紹介したページです．

Dustin Boswell・Trevor Foucher 著，角征典 訳 (2012)「リーダブルコード」オライリージャパン．（Dustin Boswell and Trevor Foucher (2011) “The Art of Readable Code,” O’Reilly Media.）

コードは他の人が最短時間で理解できるように書かなければいけない．

簡単な書籍の紹介

ボズウェルとフーシェによる「リーダブルコード」は，コードの改善方法について教えてくれます．
変数の命名からコードの構成にいたるまで，アドバイスしてくれる一冊です．

目次

第I部　表面上の改善

• 1章　理解しやすいコード
  • 1.1　「優れた」コードって何？
  • 1.2　読みやすさの基本定理
  • 1.3　小さなことは絶対にいいこと？
  • 1.4　「理解するまでにかかる時間」は競合する？
  • 1.5　でもやるんだよ
• 2章　名前に情報を詰め込む
  • 2.1　明確な単語を選ぶ
    • もっと「カラフル」な単語を探す
  • 2.2　tmpやretvalなどの汎用的な名前を避ける
    • tmp
    • ループイテレータ
    • 汎用的な名前のまとめ
  • 2.3　抽象的な名前よりも具体的な名前を使う
    • 例：DISALLOW_EVIL_CONSTRUCTORS
    • 例：--run_locally
  • 2.4　名前に情報を追加する
    • 値の単位
    • その他の重要な属性を追加する
  • 2.5　名前の長さを決める
    • スコープが小さければ短い名前でもいい
    • 長い名前を入力するのは問題じゃない
    • 頭文字と省略形
    • 不要な単語を投げ捨てる
  • 2.6　名前のフォーマットで情報を伝える
    • その他のフォーマット規約
  • 2.7　まとめ
• 3章　誤解されない名前
  • 3.1　例：filter()
  • 3.2　例：Clip(text, length)
  • 3.3　限界値を含めるときはminとmaxを使う
  • 3.4　範囲を指定するときはfirstとlastを使う
  • 3.5　包含／排他的範囲にはbeginとendを使う
  • 3.6　ブール値の名前
  • 3.7　ユーザの期待に合わせる
    • 例：get*()
    • 例：list::size()
  • 3.8　例：複数の名前を検討する
  • 3.9　まとめ
• 4章　美しさ
  • 4.1　なぜ美しさが大切なのか？
  • 4.2　一貫性のある簡潔な改行位置
  • 4.3　メソッドを使った整列
  • 4.4　縦の線をまっすぐにする
    • 整列すべきなのか？
  • 4.5　一貫性と意味のある並び
  • 4.6　宣言をブロックにまとめる
  • 4.7　コードを「段落」に分割する
  • 4.8　個人的な好みと一貫性
  • 4.9　まとめ
• 5章　コメントすべきことを知る
  • 5.1　コメントするべきでは「ない」こと
    • コメントのためのコメントをしない
    • ひどい名前はコメントをつけずに名前を変える
  • 5.2　自分の考えを記録する
    • 「監督のコメンタリー」を入れる
    • コードの欠陥にコメントをつける
    • 定数にコメントをつける
  • 5.3　読み手の立場になって考える
    • 質問されそうなことを想像する
    • ハマりそうな罠を告知する
    • 「全体像」のコメント
    • 要約コメント
  • 5.4　ライターズブロックを乗り越える
  • 5.5　まとめ
• 6章　コメントは正確で簡潔に
  • 6.1　コメントを簡潔にしておく
  • 6.2　あいまいな代名詞を避ける
  • 6.3　歯切れの悪い文章を磨く
  • 6.4　関数の動作を正確に記述する
  • 6.5　入出力のコーナーケースに実例を使う
  • 6.6　コードの意図を書く
  • 6.7　「名前付き引数」コメント
  • 6.8　情報密度の高い言葉を使う
  • 6.9　まとめ

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

• 7章　制御フローを読みやすくする
  • 7.1　条件式の引数の並び順
  • 7.2　if/elseブロックの並び順
  • 7.3　三項演算子
  • 7.4　do/whileループを避ける
  • 7.5　関数から早く返す
  • 7.6　悪名高きgoto
  • 7.7　ネストを浅くする
    • ネストが増える仕組み
    • 早めに返してネストを削除する
    • ループ内部のネストを削除する
  • 7.8　実行の流れを追えるかい？
  • 7.9　まとめ
• 8章　巨大な式を分割する
  • 8.1　説明変数
  • 8.2　要約変数
  • 8.3　ド・モルガンの法則を使う
  • 8.4　短絡評価の悪用
  • 8.5　例：複雑なロジックと格闘する
    • より優雅な手法を見つける
  • 8.6　巨大な文を分割する
  • 8.7　式を簡潔にするもう1つの創造的な方法
  • 8.8　まとめ
• 9章　変数と読みやすさ
  • 9.1　変数を削除する
    • 役に立たない一時変数
    • 中間結果を削除する
    • 制御フロー変数を削除する
  • 9.2　変数のスコープを縮める
    • C++のif文のスコープ
    • JavaScriptで「プライベート」変数を作る
    • JavaScriptのグローバルスコープ
    • PythonとJavaScriptのネストしないスコープ
    • 定義の位置を下げる
  • 9.3　変数は一度だけ書き込む
  • 9.4　最後の例
  • 9.5　まとめ

第III部　コードの再構成

• 10章　無関係の下位問題を抽出する
  • 10.1　入門的な例：findClosestLocation()
  • 10.2　純粋なユーティリティコード
  • 10.3　その他の汎用コード
    • 思いも寄らない恩恵
  • 10.4　汎用コードをたくさん作る
  • 10.5　プロジェクトに特化した機能
  • 10.6　既存のインタフェースを簡潔にする
  • 10.7　必要に応じてインタフェースを整える
  • 10.8　やりすぎ
  • 10.9　まとめ
• 11章　一度に1つのことを
  • 11.1　タスクは小さくできる
  • 11.2　オブジェクトから値を抽出する
    • 「一度に1つのタスク」を適用する
    • その他の手法
  • 11.3　もっと大きな例
    • さらなる改善
  • 11.4　まとめ
• 12章　コードに思いを込める
  • 12.1　ロジックを明確に説明する
  • 12.2　ライブラリを知る
  • 12.3　この手法を大きな問題に適用する
    • 解決策を言葉で説明する
    • 手法を再帰的に適用する
  • 12.4　まとめ
• 13章　短いコードを書く
  • 13.1　その機能の実装について悩まないで――きっと必要ないから
  • 13.2　質問と要求の分割
    • 例：店舗検索システム
    • 例：キャッシュを追加する
  • 13.3　コードを小さく保つ
  • 13.4　身近なライブラリに親しむ
    • 例：Pythonのリストとセット
    • ライブラリの再利用はなぜいいことなのか
  • 13.5　例：コーディングするよりも
    • Unixツールボックスを使う
  • 13.6　まとめ

第IV部　選抜テーマ

• 14章　テストと読みやすさ
  • 14.1　テストを読みやすくて保守しやすいものにする
  • 14.2　このテストのどこがダメなの？
  • 14.3　テストを読みやすくする
    • 最小のテストを作る
    • 独自の「ミニ言語」を実装する
  • 14.4　エラーメッセージを読みやすくする
    • もっといいassert()を使う
    • 手作りのエラーメッセージ
  • 14.5　テストの適切な入力値を選択する
    • 入力値を単純化する
    • 1つの機能に複数のテスト
  • 14.6　テストの機能に名前をつける
  • 14.7　このテストのどこがダメだったのか？
  • 14.8　テストに優しい開発
  • 14.9　やりすぎ
  • 14.10　まとめ
• 15章　「分／時間カウンタ」を設計・実装する
  • 15.1　問題点
  • 15.2　クラスのインタフェースを定義する
    • 名前を改善する
    • コメントを改善する
  • 15.3　試案1：素朴な解決策
    • このコードは理解しやすいか？
    • 読みやすいバージョン
    • パフォーマンスの問題
  • 15.4　試案2：ベルトコンベヤー設計
    • 二段階ベルトコンベヤーの実装
    • これで終わり？
  • 15.5　試案3：時間バケツの設計
    • 時間バケツの実装
    • TrailingBucketCounterを実装する
    • ConveyorQueueの実装
  • 15.6　3つの解決策を比較する
  • 15.7　まとめ