概要
「Clean Code アジャイルソフトウェア達人の技」を読み、コードをキレイにするために重要だと感じたルールを簡単にまとめました。他の人が自分のコードを読みやすくするため、拡張性、保守性の高いコードにするために重要なものだと思います。
関数
メソッドはなるべく小さく(3,4行)
一つのメソッドで1つの役割。複数のプロセスを含む場合は分解する。インデントは1つか2つまで
if文やfor文でのネスティングは少なめにする。メソッド内の抽象度レベルを揃える。
わかりやすいメソッド名。
初めてコードを読む人でも何を表しているかわかるように。引数は少なく。0が理想、2つ以下。
booleanは引数にしない。booleanを引数として渡しているのは、中で条件分岐しているということ。副作用をなくす。(隠れたプロセス)
メソッド名などからはわからない、隠れた処理はなくす。関数の呼び出し元を見なくてもわかるようにする。
メソッド名で何をしているかわかるように。try catchの中身はメソッドに切り出す。
try, catchを使うと、どうしても見づらくなるため。DRY(Don't repeat yourself)原則。
同じコードを繰り返さない。条件式のカプセル化。できるだけ肯定形で。
!やnot◯◯はできるだけ使わない。
書式化
変数、privateメソッドは使う場所の近くに書く。
縦方向に大きくスクロールする必要がなくなり、見やすい。説明的変数を使う。
計算過程の値に変数名をつける。境界条件のカプセル化
条件式などで使われる境界値を変数名として抽出する。メソッドは抽象度レベル順に並べる。
コメントはできるだけ使わない。
メソッド名、変数名、クラス名でわかるようにする。
オブジェクトとデータ構造
手続き型は後から関数を追加しやすい。オブジェクト指向はクラスを追加しやすい。
-
デメテルの法則
オブジェクトを使用する際、そのオブジェクトの内部について知るべきではない。クラスの依存関係を減らす。
例外処理
- 非チェック例外を使う。
- エラーコードではなく例外クラスを返す。
- catchしたところで、十分なログを書く。
nullを返さない。
nullチェックが多くなりがち。空リストなどにして返すことで対処する。nullを引数として渡さない。
nullが渡されたときに上手く対処できるメソッドは少ない。nullを渡すことは原則禁止にした方が良い。
境界
- 外部連携が必要な際、まだ存在しないコードはインターフェースを使う。
テストコード
何をテストしているかわかりやすくする。
1. 1つのテストに1つのassert。
2. 1つのテストで1つの概念。
クラス
- 変数はprivateにする
- SRP(single responsibility principle) 1つのクラスに1つの役割。
単純な設計のための4つの規則
上から順に優先順位が高い。(②と③は同じぐらい)
①Passes the tests(テストが通ること)
テストが通ること。意図した通りにコードが動作することを常に検証できる。
②Reveals intention(意図が明快であること)
良い命名、関数とクラスを小さく保つこと、デザインのパターンの適用などにより、書き手の意図を明快にする。
③No duplication(重複の排除)
④Fewest elements(クラスとメソッドを最小限に)
関数とクラスの数を少なくする。
まとめ
コメントを使わず、コードを読めば何をしているかわかるようにするのが理想だと思います。変数名、メソッド名、クラスの分け方などを工夫し、個人的には自然言語を読むのと同じように読めるコードを書けるようにしたい感じました。
また、テストがあれば思い切って、リファクタリングできます。いつでもコードをキレイにできるよう、TDDなどを駆使して、テストは常に十分に書いておきたいです。実際にはコードをキレイにする時間をなかなか取れないことが多いですが、「ボーイスカウトの規則」を意識して、自分が見つけたコードは、見つけた時よりもキレイにして、汚いコードを減らしていこうと思います。