コーディングの掟 - 神様なんて信じない僕らのために

不可解なJavaコードを題材にして、
何故かを考えたり、
よりよい方法を提示したりするような内容。
提示されるコードの大半がJavaであるため、
C/C++よりもJava寄り、また趣味プログラミングよりも業務プログラミング（集団向け）ではあるが、

if ("".isEquals( str )) {
    ...
}

のような、NullPointerExceptionを避けるようなコードは自分も嫌いなので、
面白く読むことができた。
C/C++でも、

if (1==hoge) {

}

みたいな代入と評価を間違えたときにも大丈夫なようなコードを書くべき、
みたいな話題があるが、
実際、これらはコンパイラのWarningで回避すべきであって、
可読性を減じる可能性をもってまで
小手先のテクニックで何とかすべきではないと思う。

他にもclass Globalなんてものがでてきたり、
バージョン管理システムをリーダー一人のPCにいれて運用しているような話がでてきて、
面白い読み物としても読めた。

ソースコードをある程度の期間書くと、
既存のソースコードにきな臭さを感じられるようになる。
ソースコードだけでなく、設計とか環境とかもそうだけど。
このきな臭さには種類があって、

「俺のやり方と違っていて気に入らない」
「あーあーあー、××の本にこうしろって書いてあったのになんでこんな書き方を」
「経験上、こういう書き方をしているとき、こういう事例があったのでこれは避けた方が良い or 改善した方が良い or 相談した方が良い」

とかなんとか。
大切なのは気分とか好みでこれらの規約や書き方を定めないこと。
きな臭く思っている自分こそがきな臭いのではないか、と考えること。

自分も、
型名を全て大文字にしろ、という巫山戯た規約と付き合ったことがあるが、
何の意味もない上に、悪癖となって残るという最悪の規約だった。

int -> INT
short -> SHORT
char -> CHAR
void -> VOID

とかすることに、何の意味もない。
（標準からあえて外れるというデメリットしかない）

コーディングをする差違には常に、
「なぜそうしなければならないか？」
を考えるべきであり、
考えずにコーディングをすることなかれ、ということであり
そういう意識を持ったり育てたりすることにおいて、
読み物として読むことができるこの本は良い本だと思う。

作法を読んだことがない人はまず作法を読むべきだけどね。
（これらにおいて、作法に適う本は殆どない）