読者です 読者をやめる 読者になる 読者になる

コーディングの掟

不可解な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


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


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


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

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

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


プログラミング作法

プログラミング作法