著作一覧 |
御伽噺のような話だ。
個人的には嫌いなのだがやんごとなき理由からCheckStyleというツールを使っている。
困ったことに、初心を忘れて好きになりかけている自分がいたりもするのだが、それはおいておいて。
一応、良くあるルールは入っていて、たとえばstaticメソッドしか定義されていないつまるところユーティリティにはprivateコンストラクタが無ければ怒るとかなっている。
このコーディング規約ってのは、個人的にはあまり意味がないと思うのだが、おそらく
public class Utility { /** * 与えられた文字列をnullに変換する。 * @param s nullにする文字列 * @return null * @throws NullPointerException 与えられたsがnull */ public static String convertToNull(String s) { if (s == null) { throw new NullPointerException("null was given"); } return null; } }
というようないかしたユーティリティに対して
public bar(String arg) { String s = new Utility().convertToNull(arg); ... }
みたいなすっとぼけた利用方法を防止することが目的なんだと思う。
実際にはとっくの昔に役割を終えていて、こういうのって警告が出るような気がするのだが(わざわざこんな書き方しないからわかんないけど)、バージョン管理を考えるとあまりよろしくないルールのような気がするのだが、それはまた別の話である。
で、そういうルールがあってこれをCheckStyleがチェックするというわけだ。
で、そんなある日のこと、愉快なソースを眺めていたら
public class CoolUtility { /** * 新しいCoolUtiltityを作る (といった文) */ public CoolUtility() { } public String bornClash(int x) { return String.valueOf(x); } public String bornClash(long x) { return String.valueOf(x); } ... 山ほどたくさん。 }
というような、すばらしくぼんくらなクラスが出てきたので腰を抜かした。
どうあってもString.valueOfを使いたくないらしいというのには目を瞑るとしても、なんでこれがインスタンスメソッドなんだ?
すると隣の席の人いわく
このコンストラクタのJavadocにはEclipseの匂いがする。
出たー。Eclipseか(追記:誤爆の可能性あり。更に追記:誤爆確定(って、ことは小僧以下だな。確信のもとにコンストラクタを書いているということになる。――無引数publicコンストラクタ書けルールのほうかな? でもあのルールは殺しているはずだが))。何しろ小僧の神様だからなぁ。神様がなされたことはすべからず善であるから消すなんておそれおおくてできないだろうし。ってことは、いくらなんでも最初はstaticメソッドとして実装してみたが、CheckStyleが怒った(privateコンストラクタじゃないわけだから)もんで、ごめんなさい、ごめんなさい、って謝りながらメソッドからstaticを消して行ったんだろうなぁ。(注:「すべからく」じゃないのは意図した誤動作)
かくしてCheckStyleは文句を垂れなくなりました。めでたし。
実に工夫の後が見える実装である。
教訓:小僧にEclipseを与えてはならない(実にたくさんメソッドが入っていたわけで、だめなコードの生産性を高めては本末転倒であろう。より生産性が低いツールを与えた方がプロジェクト全体としては効率が向上する可能性がある)。または重箱の隅をつつくようなコーディング規約の厳密なチェックは、より質の低下を招く。
注:骨を砕くんじゃなくて、生まれてきてごめんなさいの意がこもったメソッド名だという点を味わって欲しい
ジェズイットを見習え |
通りがかるのも3度目なので識別子(コテハン)を。<br><br>Eclipseでコンストラクタのスタブ作るとふつー中にsuper();が入ってるのでEclipseは冤罪のような…「神様」の設定弄るとも思えないし。
え、Object派生クラスにもそんな冗長なものを入れるんですか? 恐るべし…
そういえばCheckStyleでチェックしてるのは15ポイントルールだけだ・・・他のチェック何一つしてない・・・何か使い方を間違えてる気がする(笑)
CheckStyle は使ったことがないのですが、CoolUtility クラスにインスタンスフィールドがないことは警告してくれないのでしょうか。
>スタンスフィールドがないことは警告してくれないのでしょうか<br>これはされたら迷惑でしょう。ストラテジやビジターなんかだと必ずしもフィールドを持つ必要は無いからそんなことで文句を垂れられたらさすがに使えない。
日本語化した3.0デフォルトで「スーパークラスからのコンストラクター」にチェック入れてObject派生クラス作るとこんなのでした。<br><br>/**<br> * @author hogehoge<br> *<br> * TODO この生成された型コメントのテンプレートを変更するには次へジャンプ:<br> * ウィンドウ - 設定 - Java - コード・スタイル - コード・テンプレート<br> */<br>public class Hoge {<br><br> /**<br> * <br> */<br> public Hoge() {<br> super();<br> // TODO 自動生成されたコンストラクター・スタブ<br> }<br><br>}
どうもありがとうございます。注記を本文に入れました。