Java/コーディング規約/自分の規約

コーディング規約、というよりは「こうすべき理由」を列挙したものなので、そのうち他のページに移動する予定。

宣言の順序 #

javap で逆コンパイルしたときの順番を使う。

たとえば、メソッドの場合、「public static final transient int」てな順序。

インデント、桁数 #

• インデントは4文字のスペース。
• 環境に依存するので、TABは使用しない。
• １行は96桁以内に納める。ただし、ソースコードの読みやすさを重視
  • 80桁だと少々少ないし、そのせいで短くてわかりにくいメソッド名をつけてしまっては本末転倒なので。
    • （でも、長いメソッド名をつけたくなったときは、クラスの分割・整理が不十分なのかも）

for文 #

for文の基本パターン。

配列へのアクセス:

for (int i = 0, s = array.length; i < s; i++) {
}

終了判定の高速化のため、ループ開始時に終了値を取得(s)、 これを使って判定する(i < s)。

• 's'をfinalにできないのは不満だが。

コレクションへのアクセス:

for (final Iterator i = collection.iterator(); i.hasNext();) {
    final ItemType item = (ItemType)i.next();
     : 
}

少なくともLinkedList系の、get(index)のコストが高いコレクションを使うときは、 Iterator経由でアクセスすること。あるいは、いったん配列にすること。

finalの使用 #

出来る限りfinalを使用する

private void sample(final String name, final int value) {
    //
    for (final Iterator i = collection.iterator(); i.hasNext();) {
        final Item item = (Item)i.next();
        final String n = item.name();
        final String v = item.value();
        if (n.equals(name)) {
            item.value(value);
        }
    }
}

例外処理 #

• 例外処理は「Javaのライブラリが発生する例外」と「アプリケーションの例外」に分ける。
• 通常、「Javaのライブラリが発生する例外」は適切な階層で処理し、 必要であれば「アプリケーションの例外」でラップする。
• 「アプリケーションの例外」は アプリケーションの内部状態の矛盾を避けるために使用し、適切な場所でcatchして、 処理フローを遷移させる。
  • 例：ソケットがクローズされたとき、ソケットの読み書きを行う処理フローを回避する。
• あらかじめエラーチェックを行うことで例外が発生する処理を回避できるなら、そのようにする。
  • 例：ファイルオープンの前に、ファイルが存在することを確かめる。

• アプリケーションの例外で、Exception（チェックされる例外）と RuntimeException（チェックされない例外）のどちらを継承するか 判断するのは難しい。
• Exceptionのデメリット
  • メソッドのシグネチャの一部であるため、内部の実装に影響されてしまうので、 Interfaceの一部にするは難しい。
    • 例：ファイルオープン→読み込みの２つのメソッドがあるが、 実装時に、ファイルオープンでは何もせず、最初の読み込み時にファイルオープンを行うようにした 場合、メソッドのシグネチャが変化してしまう。
  • リフレクションを使った場合は、チェックされないので、完全ではない。

• 例外はスレッドの外には出ない。よって、mainだけではなく、おのおののスレッドのrunメソッドでも 例外を拾う必要がある。また、スレッドで発生した例外をmainに通知する機構が必要になるかもしれない。