magazine.gifリーダブルコード

目次
訳者まえがき
はじめに

1章 理解しやすいコード

  • 1.1 「優れた」コードって何?
  • 1.2 読みやすさの基本定理
  • 1.3 小さなことは絶対にいいこと?
  • 1.4 「理解するまでにかかる時間」は競合する?
  • 1.5 でもやるんだよ

第I部 表面上の改善
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 まとめ

付録 あわせて読みたい

  • 高品質のコードを書くための書籍
  • プログラミングに関する書籍
  • 歴史的記録

解説(須藤 功平)

  • 実際にやる
    • 実際にやるとぶつかること
    • 他の人に読んでもらう
    • おさらい
  • 当たり前にする
    • 既存のコードを読みやすくする前にやること
    • 続けることが大事
  • コードで伝える
    • 読みやすいコードがもっと当たり前であり続けるために
    • コミットメールのススメ
    • まずはあなたが読む
    • 添削コミット
    • おさらい
  • 最後に

索引