if文の左辺値やメソッドの実引数に代入ロジックを入れると、文が読みにくくなります。
if ((x = getX()) == 10) ... // こんなのとか bar(v = calculate()); // こんなのもそう
PMD : AssignmentInOperand
CheckStyle : InnerAssignment
Javaでは、\xxx によって8進数表記が可能ですが
8や9を記述するとその時点で8進数表記が終了したと解釈されます。
"\012" -> アスキーコード10の文字を表す "\018" -> アスキーコード1の文字 + "8" を表す
しかし、後者のような記述法は非常にわかりにくいので避けた方が無難です。
PMD : SuspiciousOctalEscape
JavaではCのような参照型という概念が存在しない為、
メソッドパラメータに値を代入しても
その値を呼び出し元に返すことが出来ません。
public void foo(int v, String message, Bean bean) {
v = 10; // パラメータへの代入
message = "after message"; // これも同様
bean.setX(10); // パラメータのメソッド呼び出しはOK
}
public void bar() {
int v = 1;
String message = "before message";
Bean bean = new Bean();
bean.setX(5);
foo(v, messgae, bean);
log(v); // v の内容は 1
log(message); // message の内容は "before message"
log(bean.getX()); // getX() は 10 を返す
}
パラメータへの代入処理は、処理ロジックの理解を難解にする傾向にあります。
ですので、可能な限りこれらは避けた方が良いのです。
PMD : AvoidReassigningParameters
CheckStyle : ParameterAssignment
FindBugs : IP: A parameter is dead upon entry to a method but overwritten
こんなコードがあります。
private int count;
private void bar(int count) { // パラメータとして定義…(A)
...
}
private void foo() {
int count; // ローカル変数として定義…(B)
...
}
private void setCount(int count) { // Setterのパラメータとして定義…(C)
this.count = count;
}
フィールドとして定義された count と同名の
パラメータやローカル変数があります。
これは紛らわしいので、ある程度の制限を設けるべきです。
個人的には、(A) や (B) のケースは避けるようにします。
ただし (C) のケースは許可しても構わないと思います。
Getter/Setterを自動生成していれば問題ありません。
CheckStyle : HiddenField
FindBugs : MF: Method defines a variable that obscures a field
単一メソッドの中から複数の箇所にreturn文が記述されていると、
処理の流れがつかみずらくなる危険性があります。
なるべく、メソッドの最後に一つだけreturn文を配置しましょう。
CheckStyle : ReturnCount
.* 形式のimport文は便利ですが、使わないことをお勧めします。
理由としては、
などが挙げられます。
Eclipseを使っている人は、Preferencesの「Organize Imports」に
「Number of imports needed for .*」という項目があるので
これを99(デフォルト)のようにしておきましょう。
まさか、今どき手動でimport文を記述している人はいません…よね？
CheckStyle : AvoidStarImport