例によって括弧書きはコメント
○第５章 書式化
チームで仕事をしているなら1つの書式ルールで合意をとり、すべてのメンバーはそれに従うべき。
(当たり前のことだけどできてないことが多いコードが多い。ルールを文書化しておくと規約に沿ってないコードを書いたときも指摘しやすい。静的解析ツールのルール定義をしておくのもありかなと思う。)
コードの書式化は宗教戦争の引き金ではなく、長期にわたって保守容易性と拡張性を提供してくれるもの。
大きなファイルよりも小さなファイルの方が理解しやすい、当たり前のこと。
ソースファイル中の記述は抽象レベルが高いものが上、実装詳細が下にあることが望ましい。新聞と同じ構造。
縦方向で書式化に関連するのは空行の入れ方。パッケージ宣言、インポート文、各関数など別の概念のものは空行を挟むと良い。
逆に一続きの処理の間に空行がはいると読みにくくなる。関連するコードは空行を挟まず、物理的に近い位置に記述できることが望ましい。
変数宣言は使用位置に近いところで、ループ変数はループの中で宣言する。
横方向の書式化はインデントや空白、1行の文字数がある。
文字数はモニタに入りきるぐらいで、120文字ぐらいがいいのではないか。
空白をうまく挟むことで処理を強調できる。代入の左右に置くと変数名が読みやすくなるし、計算式の途中に入れると演算子の優先順位が読みやすくなる。
タブを使った変数の位置合わせは意味が無い。位置あわせしないと読みづらいような宣言はそもそも何かおかしい(関数／クラスが大きすぎる とか)。
○第６章 オブジェクトとデータ構造
すべてのメンバにゲッタとセッタを用意するのはアホのすること、最悪。
目指すべきは「抽象インターフェースを公開することで、データの実装を知らせること無しに利用者に対してデータの本質を操作することを可能とする。」
データ／オブジェクトには非対称性があり、状況に応じて使い分けることが大事。
データ構造(structとか)を使用するコードは新たな関数を既存のデータ構造に影響を与えずに追加することが可能。オブジェクト指向の場合、既存の関数を帰ること無く新たなクラスを追加することが可能。
言い換えると
データ構造を使用するコードは、新たなデータ構造を追加する場合、既存関数全てに手を入れる必要がある。オブジェクト指向の場合、新たな関数を追加する場合、既存クラス全てに手を入れる必要がある(interfaceを使った場合ね)。
○第７章 エラー処理
エラー処理は重要だが、エラー処理のせいでロジックが不明瞭になっているとしたらそれは間違っている。
例外が使えるなら戻り値によるエラー情報でなく、例外を積極的に活用する。
3rd partyのライブラリなど多数の例外に対応する必要がある場合はラッパを作って、不要な例外処理をロジック側に書かなくてもよくする工夫も有効。
nullは返さない、nullを渡さない。
nullを返す実装を作ると呼び出し側でチェックが必要になり、記述が複雑になる。空のリストを返すとか工夫をすることで、nullを返すのと同じ効果を得ることが可能なはず。
nullを渡すコードを原則禁止にしてしまえば、nullが渡って来た場合、誤りであるとすぐに気づくことができる。
