読みやすいコードを書くのに「面白い」ことをする必要はない。いい名前をつける。適切なコメントを書く。意味のある単位に分割する。キレイに整形する。こうした基本的なことを着実にやればいい。このことを丁寧に説明してくれるのが本書である。
（「訳者まえがき」より）
「本書の目的は、君のコードをよくすることだ。」（「はじめに」より）
勤務先のCTOから「これを読むように」と本棚から手渡されたのが本書。
「本書は楽しく気楽に読んでもらいたい。できれば１〜２週間で読んで欲しい。」（「はじめに」より）
楽しく気楽に読めるかは定かでないが、２週間以内には１周目を読み終えたい。
本書の1章のサマリーをまとめていく。
1.1 「優れた」コードって何？
コードを書くうえでいちばん大切な原則は、
「コードは理解しやすくなければならない。」
プログラマは直感でプログラミングのことを決めていることが多いが、「簡潔」なコードと「安心」なコードではどちらが大切なんだろうか？
ここでいう「簡潔」なコードと「安心」なコードは以下のようなものだ。
/* 簡潔 */
return exponent >= 0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);
/* 安心 */
if (exponent >= 0) {
return mantissa * (1 << exponent);
} else {
return mantissa / (1 << exponent);
}
1.2 読みやすさの基本定理
「コードは他の人が最短時間で理解できるように書かなければいけない」
「コードを理解する」というのは、
・変更を加えたり
・バグを見つけたり
できるという意味。
他のコードと連携する方法も理解しておかなければいけない。
「他の人」とは
・6ヶ月後の君自身
・君のプロジェクトに途中から参加する人
・他のプロジェクトで再利用する人
1.3 小さなことは絶対にいいこと？
コードは短くした方がいい。ただし、理解するまでにかかる時間を最短にするためには、
・行を分ける
・コメントをつける
方が大切。
1.4 「理解するまでにかかる時間」は競合する？
高度に最適化されたコードであっても、もっと理解しやすくできる。
理解しやすいコードは優れた設計やテストのしやすさに繋がることが多い。
常に一歩下がって、「このコードは理解しやすいだろうか？」と自問自答することが大切。
1.5 でもやるんだよ
想像上の誰かが自分のコードを理解しやすいかなんて考えるのは大変だが、
これまでとは違う脳味噌を回転させなきゃいけない！