目次

第1章　プログラムを読もう

1.1　プログラムを読むということは……

1.2　プログラムを読む理由

• 1.2.1　知識/技術を学ぶため
• 1.2.2　開発中のプログラムのレビュー
• 1.2.3　既存のプログラムをメインテナンスするため

1.3　“駆け出しプログラマー”に足りないもの

• 1.3.1　失敗に取り組む力が乏しい
• 1.3.2　写経とパッチワークと穴埋めの経験しかない
• 1.3.3　アルゴリズム、イディオム、デザインパターンなどに対する理解不足
• 1.3.4　プラットフォームに対する理解不足
• 1.3.5　良質なソースコードを読み解いた経験が少ない
• 1.3.6　プログラムの細部の振る舞いを追跡できない

1.4　プログラムの行間を読もう

• 1.4.1　データ構造、アルゴリズム、デザインパターン、イディオム、設計思想を読み解く
• 1.4.2　行間/字句間に隠蔽された振る舞いを読み解く

1.5　コメントに過度の期待はしない

• 1.5.1　コメントは、言語やライブラリに対する知識の未熟さを補完してくれるものではない
• 1.5.2　コメントは、なぜそう書いたかという理由を書きとめるもの
• 1.5.3　コメントが常に正しいわけではない
• 1.5.4　どうあるべきかは仕様書を、実際にどう動くかはコードを読むべき
• Column　コメントがソースコードより常に理解しやすいとは限らないもう1つの理由

第2章　読むために書く、書くために読む

2.1　プログラミングは体で覚えるもの

• 2.1.1　本を読んだだけではプログラミングができるようにはならない
• 2.1.2　授業や研修を受けただけではプログラミングができるようにはならない
• 2.1.3　実際に手を動かし、何が起きるかを体験してみる
• 2.1.4　できないときの悔しさ、できたときの感動を味わう

2.2　誰かに教えてみよう

• 2.2.1　他人に教えることは損ではない。むしろ得である
• 2.2.2　同僚、同級生、あるいはネット上で知り合った人に教える
• 2.2.3　教えるためには、相手の書いたコードを読まなければならない
• 2.2.4　教えるためには、もっと良いコードを書く努力が必要になる
• 2.2.5　教えることで、それまで自分がわからなかったことが明確になり、整理される
• Column　整数の除算によるオーバーフロー

2.3　読む訓練を目的として「書く」

• 2.3.1　役に立たないプログラムを書こう
• 2.3.2　制御構造をエミュレートする
• 2.3.3　誰かが用意したものではなく、自分で考えたコードを書くことの意義

2.4　書く訓練を目的として「読む」

• 2.4.1　技術は盗むもの
• 2.4.2　オープンソースを活用しよう
• 2.4.3　人の振り見て我が振り直せ

第3章　プログラムを読むために血肉化すべき素養

3.1　行間、字句間に隠蔽された振る舞い

• 3.1.1　プロシージャの振る舞い（C、C++、Java、C#、PHP）
• 3.1.2　スコープの振る舞い（C、C++、Java、C#、PHP）
• 3.1.3　デストラクタの振る舞い（C++、Java、C#、PHP）
• 3.1.4　文字列の振る舞い（C、C++、Java、C#、PHP）
• 3.1.5　ガーベジコレクションの振る舞い（C、C++、Java、C#、PHP）
• 3.1.6　演算子オーバーロードの振る舞い（C++、C#）
• 3.1.7　例外処理の振る舞い（C++、Java、C#、PHP）
• 3.1.8　「こんなときはどうなるの？」という疑問を持とう

3.2　データ構造、アルゴリズム、デザインパターン

• 3.2.1　プログラミング言語以外の知識の必要性
• 3.2.2　代表的なデータ構造
• 3.2.3　代表的なアルゴリズム
• 3.2.4　代表的なデザインパターン

3.3　言語/ライブラリ/フレームワークの知識の必要性

• 3.3.1　辞書を引きながら文章を読むことはできても、文法を調べながら文章を読むことなどできない
• 3.3.2　前提知識がなければ話題に付いていくことはできない
• 3.3.3　開発ツールのマニュアルは必ず読もう

3.4　“人間コンパイラ”を目指す

• 3.4.1　コンピュータの動作原理を知る
• 3.4.2　コンパイル結果を読もう
• 3.4.3　最適化はどのように行われるか？

第4章　ソースコードの“地図”の描き方

4.1　ソースコードの“地図”とは？

• 4.1.1　関数コールツリー
• 4.1.2　クラス図
• 4.1.3　状態遷移図

4.2　関数やクラスが定義されている場所、使われている場所

• 4.2.1　グローバル検索の使い方
• 4.2.2　クロスリファレンスの作り方
• Column　コマンドラインツールに対する食わず嫌いをなくそう

4.3　ソースコードをビジュアル化しよう

• 4.3.1　自動ドキュメント生成ツールの紹介

4.4　デバッガを使って、ソースコードを“旅”しよう

• 4.4.1　デバッガで何ができるのか？
• 4.4.2　目的地を定めよう―ブレークポイントを使う
• 4.4.3　目的地周辺の散策―ステップ実行で動作を追う
• 4.4.4　現在の状況把握―変数のウォッチで状況を知る
• 4.4.5　旅の前に地図でたどろう―机上デバッグの有効性

4.5　ソースコード整形ツールを使いこなそう

• 4.5.1　きれいに整形し直すだけで、読みやすさは劇的に向上する
• 4.5.2　本質ではないことから解放されるために

4.6　オンラインマニュアルは大切なガイドマップ

• 4.6.1　意外に活用されていない最良の情報源
• 4.6.2　エラー/警告メッセージの意味を知ろう

第5章　実際にソースコードを読んでみよう

• 5.1　まずはウォーミングアップ
• 5.2　printfを読み解く
• 5.3　vfprintfを読み解く