PMD Design ルール

UseSingletonRule(Singletonを使うべき)

コンストラクターをprivateにして潰すと回避できます。

ただ、Mainしかない物は、検査の対象からはずした方がいいかもしれません。

//よくない例
public class MaybeASingleton {
    public static void foo() {
     // etc
    }
    public static void bar() {
     // etc
    }
}
//大丈夫な例 privateなコンストラクターを追加
public class MaybeASingleton {
	private MaybeASingleton {
	
	}
    public static void foo() {
     // etc
    }
    public static void bar() {
     // etc
    }
}

エラー文

All methods are static. Consider using Singleton instead. Alternatively, you could add a private constructor to silence this warning.

LooseCouplingRule(Interfaceがあるならそれを使うべき)

もしこれで他がエラーがでるようなコードの書き方が古い場合がある。

もうVectorはaddElementではなくadd、elementAtではなくgetを使うべきなんですね。

Avoid using implementation types like 'Vector'; use the interface instead

//よくない例
private Vector vec=new Vector();
//大丈夫な例
private List vec=new Vector();

SimplifyBooleanReturnsRule(boolean返すだけなら、if elseは使うな)

慣れの問題なのでしょうか、違和感があります。

//よくない例
if(x==0){
return true;
else
return false;
//大丈夫な例
return x==0;

SimplifyBooleanExpressions

不明

SwitchStmtsShouldHaveDefault(switchにはdefaultを記述するべき)

これはdefaultに、例外処理を書いて、

値を逃がさないようにするためでしょう。

AvoidDeeplyNestedIfStmts(深いネストは読みにくい)

リファクタリングサインです。

AvoidReassigningParametersRule(引数文字列に値を設定するな)

引数の文字列オブジェクトはそのメソッドの中だけで有効なオブジェクトです。

このオブジェクトに変更を加えても元にはなんら影響がありません。

混乱の元になるので、このオブジェクトに値を再設定してはいけません。

コードが長くてどこで代入しているかわからない場合、

引数にfinalをつけると、Eclipseとかなら、場所を見つけてくれます。

//よくない例
public class Foo {
 private void foo(String bar) {
  bar = "something else";
 }
}
//大丈夫な例
public class Foo {
 private void foo(String bar) {
  String bar2 = "something else";
 }
}

SwitchDensity(Switchの中で多くのことをするべからず)

見やすくするため?中の処理をリファクタリングするべきだ。

//よくない例
switch (x) {
         case 1: {
           System.out.println("I am a fish.");
           System.out.println("I am a fish.");
           System.out.println("I am a fish.");
           System.out.println("I am a fish.");
           break;
         }
//大丈夫な例
switch (x) {
         case 1: {
           doXX();
           break;
         }

ConstructorCallsOverridableMethodRule(コンストラクターの中で上書き可能なメソッドを呼んではならない)

クラスを拡張したときにうまくいかない可能性があるようです。

コンストラクトから呼ばれる

メソッドはfinalにするべきなのかな？

AccessorClassGenerationRule(Innerクラスでのprivate コンストラクターの取り扱い注意?)

FinalFieldCouldBeStatic(Finalのフィールドはstaticにするべきである)

どうせなら、staticにした方が効率がよくなる

//よくない例
public final int XXX=10;
//大丈夫な例
public static final int XXX;

BooleanInstantiation(booleanオブジェクト作るな)

無駄だから？

//よくない例
private Boolean bar = new Boolean("true"); 
//大丈夫な例
private Boolean bar = Boolean.True;

CloseConnectionRule(Connectionは閉じる)

ProperCloneImplementationRule(clone()では必ず super.clone()を呼び出すべき)

NonStaticInitializer(staticでない初期化はだめ?)

DefaultLabelNotLastInSwitchStmt(Switch文でのdefaultは最後に記述するべき)

でないと見逃すことがあるから?

NonCaseLabelInSwitchStatement(Switch中にlabelは紛らわしい?)

OptimizableToArrayCallRule(Arrayを配列に変換するときには効率よく)

//よくない例
return (String[]) vec.toArray(new String[0]);
//大丈夫な例
return (String[]) vec.toArray(new String[vec.size()]);

エラー文

This call to Collection.toArray() may be optimizable

BadComparisonRule(Dobule.NaN?)

戻る