コーディング規約

この規約は、たぶん意外と良い立場で書かれているのではと思った。コーディング規約は守られるべき法律じゃなくて、良いコードのためのパターン集であるべき。デザインパターンのように、コーディングパターンと言うべきか。

確かにそうですね。このISIDの規約は、規約というよりも良きJavaコードのために知っておくべき事という感じがしますが、自分も某C#規約と違ってよくできていると思う。

でも、適当に見ていて目に付いたやつに重箱の隅ツッコミ入れてみるｗｗ

C_MTD006 引数の数が同じメソッドのオーバーロードは利用しない（P.39）

これは一律禁止すべきではないと思う。よく利用されるケースがある。

public void print(Date hoge) {
  System.out.print(new SimpleDateFormat(this.formatStr).format(hoge));
}

public void print(Calendar hoge) {
  this.print(hoge.getTime());
}

このように内部で別のオーバーロードメソッドを呼んでいる場合など「どのオーバーロードメソッドが呼ばれても結果が同じ」場合。言い換えると「同じ名前のメソッドなのに挙動が全く異なるようなクラス設計はダメダメ」という事。クラスを分割すべき。

また、この場合

public final void print(Calendar hoge) {
  this.print(hoge.getTime());
}

オーバーロードメソッドを呼ぶメソッドをfinalにすると継承しても整合性が壊れにくい。

※ついき：finalにするだけでは不完全で、print(Date)のオーバーライドでStackOverflowの可能性がアリとのご指摘を頂きました。

print(Calendar) を final にしても整合性が壊れてしまう場合があって、具体的にどういう場合かというと「サブクラスの print(Date) が print(Calendar) を呼び出す場合」だったりする。StackOverflowError。

詳細はリンク先でご確認を…。

というわけで、プライベートメソッドを呼ぶようにする。この場合はfinal無しでもいい。

private void internalPrint(Date hoge) {
  System.out.print(new SimpleDateFormat(this.formatStr).format(hoge));
}

public void print(Date hoge) {
  this.internalPrint(hoge);
}

public void print(Calendar hoge) {
  this.internalPrint(hoge.getTime());
}

C_EXT003 catch ブロックでは必ず処理をする（P.80）

オッケーです。ただこれには規約の例外に対する補足がほしい。例外を握りつぶす場合は以下のようにしてもらえるとありがたいです。

try {
   ... 
} catch (IOException ignore) {
   // 変数名をignore（無視）等にして、プログラマはコード上に意図的に無視していることを示す、
   // かつ、ここに何故この例外を無視しているか、何故無視して問題ないのかコメントする。
}