前回のリーダブルコードまとめの続きです。
8章 巨大な式を分割する
- 式を保持する変数(説明変数)を使う
- ド・モルガンの法則を使う。複雑な論理条件はif(a<b)のような小さな条件に分割する。
- 大きなコードの塊を変数に置き換える(要約変数)。
9章 変数と読みやすさ
不要な変数があるとコードが読みにくくなる。以下のような方法で変数を減らしていく。
- 「中間結果」を保持する変数を削除する
- 変数のスコープをできるだけ小さくする。
- constやfinalなどを使ったり、一度だけ書き込む変数を使用すると、変数に何が入っているのかわかりやすくなる。
##【第三部 コードの再構成】
10章 無関係の下位問題を抽出する
- あるコードがある。そのコードの目的は「与えられた地点から最も近い場所を見つける」である。そしてそのコードの中には、「2つの地点の距離を算出する」という目的のコードがある。これを「無関係の下位問題」と呼ぶ。本来の目的とは違う下位問題を扱うコードは別の場所に分離する。
- 「無関係の下位問題」を扱うコードは、たいていの場合汎用化できる。よく使う処理は、どんなプロジェクトでも使えるような汎用コードとして別の場所に分離しておく。プロジェクト固有の処理を除き、積極的に汎用コードを作っていくよう心掛ける。
11章 一度に一つのことを
- 一度に複数のタスク（処理）を行うコードは読みづらい。大きな関数を小さな複数の関数に分離したり、大きな関数の中で論理的な段落を作ってタスクごとに分離したりするとよい。
- 読みにくいコードがあれば、そこで行われているタスク（処理）をすべて列挙する。それらのタスクを論理的に分離したり、別の関数に分けたりする。
12章 コードに想いを込める
- コードをわかりやすい言葉で説明する。アヒルや熊のぬいぐるみに対して自分のコードや問題、設計を説明する「ラバーダッキング」を行うことでより簡潔なコードが書けるようになったり、問題に対する解決策が見つかりやすくなる。
13章 短いコードを書く
出来るだけコードは書かない。コードを無駄に増やさない。
- 不必要な機能をプロダクトから削除する。過剰な機能は持たせない。
- 定期的にAPIリファレンスなどを読んで標準ライブラリでできることをわざわざコードを書いて実装するようなことを避ける。
- 最も簡単に問題を解決できるような要求を考える。
14章 テストと読みやすさ
テストコードも読みやすさが大切。
- テストコードが大きく恐ろしいものだと以下のようなことが起きる。
・テストを直すのを恐れて本物のコードを更新するのを恐れる
・新しいコードを書いたときにテストを書かなくなる - テストのために本物のコードの読みやすさを犠牲にしたり、テスト都合で本物のコードに手を加えない。
- カバレッジ100%にしないと気がすまないのはよくない。現実的にはカバレッジが100％になることはない。
- あとでテストを書くつもりでコードを書くと、テストしやすいようにコードを設計するようになる。
TDD(テスト駆動開発）は本物のコードを書く前にテストコードを書こうという手法。
TDDを導入するかはともかく、テストを意識しながらコードをかけばいいコードになる。