知人にEclipseのプラグインでCheckStyleを教えて！と言われた。もちろん仕事に使っているものなのでコードは時代柄持ち出せないんだけど、よくよく聞いていると、CheckStyleを拡張したその企業独自のオレオレプラグインになっていたらしい。内容を言うと、例外処理を書くと、どうもCheckStyleに引っかかる。なので例外処理ってどう書けばいいのかと。
「え、普通にcatch節でRuntimeExceptionに丸めてスローすりゃいいんじゃない？」って言ったんだけど、それでも駄目らしい。その時点で、２〜３日悩んでいた。高々例外処理に！どうやら、検査例外はキャッチしないで必ずスローさせるようにしたいためのチェックなのか、catch節で受け取った例外をthrowすると怒るチェックらしい。何か意図があるんだろうけど、うーん凄すぎ！メソッドを使う側が大変なことになるな、こりゃ。でも、物によってはストリームを閉じる処理なんかも入れなくてはならないため、catch節なしのfinally節だけの例外処理なんてのも書くはめに。ここまで分かるのに１週間近く。
CheckStyle自身は自分もよく使うし、仕事でも使わせるので、便利さは身にしみて分かるツモリだけど、正直ね、この一連の話を聞いていてCheckStyleなんてね、単なる道具なんだからそれを提供したらお終いってわけではないんだよねと思った。提供するほうは提供するほうで、「どういう方針、どういう風にコードを書いてほしいか」というつもりでCheckStyleを拡張したんだろうけど、それを使うほうに伝わっていなけりゃ、その正解風なコードにたどり着くまで、上のように高々例外処理だろうけど１週間もかけてしまう。CheckStyleなんて道具には人に語りかける機能はないんだよ。散文的に「ココは駄目だよ」って言ってくれるだけ。そこから意図を人間の意識の中で構成するのはたやすいことではない。
また、その１週間もかけてさいの河原で石を積む子供のように作っては（CheckStyleに）壊され、作っては・・・で作ったコードが提供する側の意図に反していたら残念なんてレベルじゃないよね。提供側からすると「駄目プログラマが・・・」ってプログラマが駄目扱い。こういうのを聞くと、工数もったいないなぁって感じる。拡張したCheckStyleにドキュメントちょっと付けりゃいいじゃん。簡単な説明会開けばいいじゃん、CheckStyleのココとココを拡張しました、ひいてはこういった処理は、このように書いてください！ってね。
以前もCheckStyleやFindBugs、シェアウエアのチェックツールのすべてのチェックを神のように崇めるように使う人を見かけたけど、道具の使い方を間違えると、もったいないことになると言う例だなぁ。
