警告とヒント

NetBeans IDE Eclipse

さて。Eclipseでいうところのコンパイラが出すエラー/警告に関するところはNetBeansでは「ヒント」というのは昨日の日記でまとめた通りですが、今日は実際にそれぞれ設定できる内容を比較してみたいと思います。

まずは、Eclipseのエラー/警告からです。そもそもの大前提として、Eclipseの場合はチェック項目に対し、違反している場合にそれを無視するか警告するかエラーにするかを設定できます。で、実際に設定できる内容は以下の通りです。

  • コード・スタイル
    • staticメンバーへの非staticアクセス
    • staticメンバーへの間接アクセス
    • インスタンス・フィールドへの限定されていないアクセス
    • 何の記述も無い空のブロック
    • エンクロージング型のアクセス不可メンバーへのアクセス
    • コンストラクター名を持つメソッド
    • パラメータへの代入
    • 外部化されていないストリング
  • 潜在的なプログラミングの問題
    • serialVersionUIDなしのシリアライズ可能クラス
    • 効果の無い代入(例えば、x = x)
    • 予期しない論理代入の可能性(例えば、'if (a = b)')
    • finallyが正常に完了しない
    • 空のステートメント
    • ストリング連結での文字配列の使用
    • 隠れたcatchブロック
    • 可変引数の型の一部が不正確
    • ボクシングおよびアンボクシング変換
    • switchでカバーされない列挙型定数
    • switch文のcaseのフォールスルー
    • Nullポインター・アクセス
    • 潜在的なNullポインター・アクセス
  • 名前のシャドーイングおよび競合
    • フィールド宣言が他のフィールドまたは変数を隠蔽
    • ローカル変数宣言が他のフィールドまたは変数を隠蔽
    • 型パラメータが別の型を隠蔽
    • メソッドがパッケージ可視メソッドを非オーバーライド
    • インターフェース・メソッドがprotectedの'Object'メソッドと競合
  • 使用すべきでは無い制限されたAPI
    • 使用すべきではないAPI
      • 使用すべきではないコード内での使用すべきではないAPIの使用を知らせる
      • 使用すべきではないメソッドのオーバーライドまたは実装を知らせる
    • 禁止された参照(アクセス・ルール)
    • 阻止された参照(アクセス・ルール)
  • 不要なコード
    • ローカル変数が読み取られない
    • パラメータが読み取られない
      • オーバーライドしたメソッドの実装を無視
      • @paramタグのパラメータ記述を無視
    • 未使用のインポート
    • 未使用のローカルまたはprivateメンバー
    • 冗長なnull検査
    • 不要なelseステートメント
    • 不要なキャストまたはinstanceof操作
    • 不要な例外スロー宣言
      • オーバーライドしたメソッドの実装を無視
      • @throwsまたは@exceptionタグの例外ドキュメントを無視
      • ExceptionおよびThrowableを無視
    • 未使用のbreakまたはcontinueラベル
    • 冗長なスーパー・インターフェース
  • 総称型
    • 未検査の総称型操作
    • raw型の使用
    • finalな型で制約された総称型パラメータ
  • 注釈
    • @Override注釈の欠落
    • @Deprecated注釈の欠落
    • 注釈をスーパー・インターフェースとして使用
    • @SuppressWarningsで処理されないトークン
    • 未使用の@SuppressWarningsトークン
      • @SuppressWarnings注釈の使用可能化


日本語の文章で書かれてもいまいち意味が分かりづらいものもありますが、まぁそれはさておき、一方のNetBeansのヒントの方も、基本的にはチェック項目に対し、違反している場合にそれを無視するか警告するかエラーにするかを設定できます。警告には、単なる「警告」と「現在の行の警告」の二種類があるようですが、いまいち意味が分かりません。で、実際に設定できる内容は以下の通りです。

  • インポート
    • 未使用のインポート
    • 禁止パッケージからのインポート
    • 同じパッケージからのインポート
    • スターインポート
    • java.langパッケージからのインポート
  • Javadoc
  • Javacの標準的な警告
    • オーバーライド
    • 不要なキャスト
    • 直列化
    • フォールスルー
    • 未検査
    • ゼロで除算
    • ifのあとの文が空
    • finally
    • 非推奨
  • エラー修正
  • API
    • 可視コンストラクタ付きのユーティリティクラス
    • SerialVersionUid
    • コンストラクタ無しのユーティリティクラス
    • 公開APIを使用して非公開な型をエクスポート
  • NetBeans開発
    • 取り消し可能なタスクに対し、cancel()が空
    • instanceOf演算子の使い方が不正
  • JDK1.5以降
    • @Override注釈を追加
    • スーパーインターフェースとして注釈を使用しない
  • 空の文
    • forの後の文が空
    • whileの後の文が空
    • if/elseの後の文が空
    • 空の文
    • doの後の文が空
  • 一般
    • 足りないhashCodeまたはequalsを生成
    • == または　!= を使用して文字列を比較
    • 二重検査されたロック
    • 自信に割り当て
    • 参照から静的フィールドにアクセス
    • フィールドが別のフィールドを隠蔽
    • 新しい変数に戻り値を割り当て
    • 間違ったパッケージ
    • 局所変数がフィールドを隠蔽
  • 中括弧
    • If-Else文には中括弧が必要
    • Do-While文には中括弧が必要
    • Whileループには中括弧が必要
    • Forループには中括弧が必要


どれがどれに対応するのか微妙に分かりづらいのでなんとも言えませんが、とりあえずぱっと見で目につくのは、「総称型(ジェネリックス)」「注釈(アノテーション)」「ボクシング・アンボクシング」等の、Java5からの機能に関する設定項目はかなりEclipseの方が多そうに見えます。その他は・・・うーん・・・単体で見れば微妙にEclipseの方が充実していそうな気がしないでもありませんが、checkstyleやfindbugsと組み合わせれば補えそうなので、特にNetBeansでも不自由しなさそうな気もします。

それにしても、世間一般的には「新機能への対応はNetBeansの方が早い」ようなことが言われているような気がするのですが、ことJava5周りに関しては微妙に対応が鈍い(ジェネリックス周りのコード補完が効くようになったのも最近だったような)気がするのは何故でしょう。

というか、その辺は微妙に従来NetBeansがEclipseに比べて弱いと言われてきたコーディングアシスト機能的なところなので、仕方ないと言えば仕方ないか

・・・

いやいや、仕方なくは無いか

フォーマッタとかテンプレートとかも比較してみたかったのですが、疲れてきたのでまた次回以降にします。