少し間が空きましたが、3章進みました。
納得できるもの、感心できるものもあれば疑問に思うところもちらほら。
○第２章 意味のある名前
いい名前を付けるには時間がかかるが、より多くの時間をあとで節約できる。
以下の命題に答えられる名前を付ける。
- なぜ存在するのか
- 何をするのか
- どう使用するのか
嘘の情報や、紛らわしい名前はさける。具体的には”意図した意味以外に使われる名前”は避ける。例えば配列名にAccountListと名付けるとList構造で実装されていると連想させてしまう。(よくこういう名前を付けてるけど混同したこと無いな・・・)
- 意味が無い名前も避ける、例えば一般的すぎる”Info”や”Data”。
- 発音できない名前は使わない。
- 検索可能な名前を使う。
- メンバ変数にプレフィックスは不要。
- ハンガリアン記法もコンパイラの方が賢いので不要。
- 解決する問題領域の用語を使う。用語集や語彙集があるといい。
- 当たり前のことだけど変数名には”名詞”、関数名には”動詞”
(最近は長い名前の変数名も使うようになった気がする。省略形をうまく作ったつもりでも引き継げないことの方が多い。
システム全体で用語集/語彙集を作っておくというのはいいかも。作ったときはコード規約に入れておくといいのかな?)
○第３章 関数
関数の原則は”小さくある”こと。一つの関数では一つのことだけを行い、それ以外のことを行わないこと。この原則に従うとif/else文やwhile文のブロック行は１行になり、関数の中にはネストされた構造も登場しなくなる。
関数の実装から別の関数を抽出できるか調べることで、関数が一つのことに集中しているかどうかを調べることができる。
関数は抽象レベルが高いものを先に記述する。こうすることでコードを物語のように読むことができる。(1ファイル中の並びはアルファベット順でいいのかと思ってた。確かに抽象度順がいいかも。)
関数の引数は0が理想、3以上は避けるべき。オブジェクトの状態を変更するようにコードを書くことで、0引数の関数が実現できる。あわせて出力先を引数で受け取るのも避けるべき(C言語ではこれは無理だ・・・)
例外を多用する、戻り値でエラーコードを返さない。エラーコードを使うとすべてのファイルが特定のエラーコードが記述されたファイルを参照するようになり、そのファイルの修正がしにくくなる。
try〜catchでエラーを補足するのも１つの処理になるので、エラーを補足する関数も別途分ける。
- 副作用をさける。
- 処理を行う関数と、応答を返す関数は分ける。
- 最初から完璧な関数が書ける訳は無い。
○第４章 コメント
「ダメなコードをコメントで取り繕っては行けない。書き直すのだ。」
適切なコメントのあり方は、コードでうまく表現することに失敗したとき、それを補うのに使うこと。
コメントの使用がダメな理由は古いコメントはメンテナンスされる保証が無いから。
コメントを書く労力はコメント無しでコードを明確化する努力に当てるべき。
不正確なコメントがあるぐらいなら無い方がマシ。書かずに済むコメントよりも良いものは無い。
必要なコメントもある
- 著作権／著作者の表示
- 意図の説明
- 曖昧な引数・戻り値の明確化
- 結果に対する警告(この処理はスレッドセーフじゃないとか)
- TODOコメント
ダメなコメントの例
- プログラマの独り言、コードの他の箇所も理解していないと意図が分からないようなもの
- 冗長なコメント(以下はデフォルトコンストラクタ とか)、コードの処理以上に説明しているコメント
- 変更記録 → ソースコード管理システムに任せましょう
- 閉じ括弧コメント→括弧の対応が1画面内に収まるぐらいに整理する
