非常に読み易くためになる本だった。B５サイズの本でさらに２００ページちょっとしかないのですぐ読る。再確認したい時などはコンパクトにまとまっていて扱いやすい。
内容的にまったく新しいということはないが、再確認やこの手の本の最初に読む本としては十分ありだと思う。
以下大まかな内容。（本の章に対応しているわけではなく、自分なりに解釈し直したもの）
ロジックとは関係ないところの読みやすさについて
名前をどう付けるか
誤解されない名前の付け方
関数名、限界値、範囲、ブール値
コードの見た目のきれいさー＞意味を理解しやすくなる、コードが追加しやすくなる
一貫性のあるレイアウト（おかしなレイアウトでも一貫性があればそれを採用する。一貫性の方が大事。）
関連するコードをまとめてブロックにする（スコープや空白で分ける）
コメント
必要ないコメント、必要なコメントとは？、正確で簡潔なコメント
ロジック周りのコードの読みやすさ
制御式の書き方
if/elseの並び順、三項演算子、do/while、関数の戻り値、ネストの深さ、追いにくいコードの局所化
式の分割
説明変数、要約変数、ド・モルガンの法則、同じ式を一つの変数にまとめる
変数の扱い方
無駄な変数を消す、変数のスコープを小さくする、変数への書き込みを減らす
コードの構成に置ける読みやすさ
汎用的に使えるコード、冗長なコードを分離する
ユーティリティ関数を作る
タスクを一度に一つ処理するようにする（一度にいろいろやろうとしない）デフラグと似ている
そのタスクが何をしているのか列挙する、分解できないか検討する
コードに思いを込める
ロジックを簡潔に説明する、説明通りに実装する
できるだけコードを書かない
必要ない要求を削除する
より単純に問題を解決する
身近なライブラリに親しむ（たまにはAPIを眺めてみる）
ライブラリを再利用する
実際の例
テストの書き方
テストを追加、変更しやすいように読みやすくする
エラーメッセージを読みやすくする（設定値、予想、結果が見えるといい）
わかりやすい入力値を設定する（意味もなく大きな値を設定したりしないなど）
テストの機能に名前を付ける（長くてもいい、説明みたいなもの）
分／時間カウンタを設計・実装する
この本の総集編
特に良かったと思う点
コメントで使い方の例を書くパターンは今までやってなかったように思う。今後はちょっと注意したい。
クラスメンバー変数の扱いについては確かに扱いにくいと何となく思っていて、どこでどのタイミングで書き変わっているのか把握しにくい場合が確かにあった。局所化するとか別のクラスにするとかちょっと考えた方が良さげ。
身近なライブラリに親しむ、という点についてすごく共感とやれてなさに耳が痛い。
コンシューマゲームでは新しいゲーム機だとSDKも新しくなる。高速化の情報とか使い方のアドバイスや使いやすいライブラリがついていたりするから、最初は一応一通りドキュメントに目を通すけどそこまでだった。新しいバージョンがリリースされた時などはほとんど確認出来ていない。またその会社が提供しているロードマップや重要な方針の変更などのニュースフィードなども取りこぼしがちだった。しっかり確認できるように自分のやり方の中に組み込もう。
