コーディングの掟（最強作法）

酷い本を読んだ。

コーディングの掟(最強作法) 現場でよく見る不可解なJavaコードを一掃せよ! (開発の現場セレクション)

この悪文の典型例は2500円もする。
現場でよく見る不可解なJavaコードを一掃するより前に、IT関連書でよく見る不可解な文章を一掃してもらいたいところ。

1. 否定文で説明した気になっている
   否定は前置きにしかならないはず。ダメなコードを挙げたならそのあとに良いコードを挙げるのが説明の基本だが、それがない。
   読者にとって無意味。
2. 例で説明しようとする
   冒頭から「たとえば」で例示、「こうしたほうがいいでしょう」で終結。
3. 主語がない
   文章の基本なのに。

例外処理の件が面白い。
「開発」を「執筆」、「例外」を「余計な例示」に置き換えるとこの本で述べられている悪例にこの本自身が当てはまってしまう。

文中で「無用な例外処理を書かなければならないので、不要な例外をthrowsしてはいけない」と述べられている一方で、不要な例示で読者の余暇を潰していたりする。しかもその例示が説明の中心になっているため、例まで読まないと論点が判らない。

「他人のコードを取り沙汰す前に自分の文章を何とかしろよ」というのが読後の感想。

こういう実装のことしか考えていない本はダメ。
実装専門の人からすればダメコードだとしても、設計を反映しているなら適切なコードなんだから。*1

d:id:pmint:20070526:p2とd:id:pmint:20070212:p2に関連記事。

*1:と聞くと「ダメ設計だから実装もダメになる」という意味で取る人多そうだなぁ…。設計の評価はまた別で、実装を見て設計を評価するようなことしちゃダメでしょ。