概要
- 一章から六章は適切な名前、優れたコメント、コードをきれいにフォーマットするやり方について
- 七章から九章は複雑なループ、巨大な式、膨大な変数の単純化について
- 十章から十三章はコードの再構成について
- 十四章は効果的で読みやすいテストの書き方について
- 十五章では本書の原則を使って問題を解決してみる
一章
- コードは他の人が最短時間で理解できるように書かなければならない
- コードを短くする < 理解にかかる時間の短縮
二章
- イテレータが複数ある時は、
i, j, kよりも、club_i, members_i, users_iまたはci, mi, uiのように明確な名前をつけた方がバグを見つけやすい - プロジェクト固有の省略形はNG, 新しくプロジェクトに参加した人も理解できなければならない 例：◯：
evaluation→eval, document→doc, ×：BackEndManager→BEManager - 長い名前は、必要な情報が損なわれなければ短くできる 例：
ConvertToString()→ToString(), DoServeLoop()→ServeLoop()
三章
- 範囲を指定するときのダメな名前の例：
start, stop.startは良いがstopはその値で終わりなのか、その値の前で終わるのか分からない. 包含的な範囲を表すのであればfirst, last, 包含/排他的範囲を指定するときはbegin, endが適切 - ブール値には
is, has, can, shouldなどをつけて分かりやすくする. また肯定系にした方が分かりやすい -
getやsizeには軽量なイメージがあるので、処理が重い時は避ける - 名前を決める時には、反対意見を考えて、誤解されない名前かどうかを検討する
四章
- 複数のコードブロックで同じようなことをしていたら、シルエットも同じようにする
- 一塊のコードは段落で分ける
五章
- コードからすぐに分かることをコメントに書いてはいけない. コードを理解するよりも、コメントを読んだ方が早く理解できるのではあれば書いても良い
- コードの読みにくさを補うコメントを書くのであれば、その読みにくいコードを改善するべき
- コードを書いてない人がハマりそうなところはコメントをつける
六章
- コメントはコードの動作をそのまま書くのではなく、コードを書いたときに考えていたことを書く. ×：listを逆順にイテレートする ◯：値段の高い順に表示する こうすることで、もし値段の高い順で表示する処理になっていなかったら、バグだと気づける
七章
-
if (length >= 10)の方がif (10 >= length)よりも読みやすい理由：言葉の用法と合ってるから. 「もし君が18歳以上ならば」が「もし18年が君の年齢以下ならば」になると読みにくい. 調査対象を先に書く - コードを短くする < 理解にかかる時間の短縮. 三項演算子はコードを短くできるが、理解にかかる時間は長くなることがある. 三項演算子で簡潔になる場合を除き、基本的にはif/elseを使おう
八章
- 論理式を等価な式に置き換えるならドモルガンの法則が使える
- 説明変数を用いることで巨大な文を読みやすくするx
九章
- コードが読みやすくならない変数は削除する
- 変数のスコープを縮め、変数のことが「見えてしまう」コードを減らす
- 変数は一度だけ書き込む
十章
- 無関係の下位問題を積極的に見つけて抽出する. つまり、プロジェクト固有のコードから汎用コードを分離する
十一章
- 関数は一度に一つのことを行う
- そのための手順
- コードが行っているタスクを全て列挙する
- タスクをできるだけ異なる関数に分割する
十二章
- コードを明確にするための手順
- コードの動作を簡単な言葉で同僚にも分かるように説明する
- その説明のなかで使っているキーワードやフレーズに注目する
- その説明に合わせてコードを書く
- ラバーダッキング
十三章
- 要求は微妙に干渉してしまう. 問題の半分を解決するのに1/4のコーディング時間で済むこともあるくらい
- 標準ライブラリの全ての関数、モジュール、型の名前を15分かけて読んでみる
十四章
- テスト関数の名前はテスト内容を表したものする. テスト関数の名前はコメントだと思えばいい
- 入出力のテストはコード1行で記述できると良い
- エラーメッセージはバグの発見や修正がしやすくなるように、手作りで作っても良い
- コードを検証する「完ぺき」な入力値を一つ作るのではなく、小さなテストを複数作る方が簡単で、効果的で、読みやすい
十五章
- 50行の読みにくいコードよりも100行の読みやすコードの方が優れている