3年目までの若手エンジニアに向けた、悪い例とその対策について多くまとめられている。具体的に類似の場面に遭遇した際に読み返すのが良い。
達人プログラマーにもある契約プログラミングやら何やらの話が出てくる。教養として本書と達人プログラマー、プリンシプルオブプログラミングは読んでおくべきかも。
なお、
...続きを読むMANNINGの電子版は固定レイアウトなので、ハイライトやメモができない。PDFやEPUBで欲しい。
【ポイント】
・コメントやドキュメントは目を通される保証がない。関数の名称や引数、戻り値の型などで内容を明確にすること。
・問題発生個所の近くでエラーを出すことで早く、可能なら目立つ(ログ送信やクラッシュなど)失敗をさせ、早期対策をする。
・Null返却やログ出力などでエラーを隠すのではなく、問題に応じた暗黙的・明示的エラー通知を用いることが望ましい。
・読みにくいコードは時間×人数で悪影響する。読みやすくすることで冗長になることがあるが、大抵の場合はメリットが上回る。
・単体テストは重要な機能を一つずつテストする。パブリックAPIに注目して行う。