CodeCoachは、クラス、メソッド、フィールド、ローカル変数、メモリー使用、その他の様々な分野についてのアドバイスを提供します。これらの各分野でCodeCoachが提案する変更は、アドバイス・タイプと呼ばれるさらに詳細なカテゴリに編成されます。このアドバイス・タイプは必要に応じて使用可または使用不可に設定できます。CodeCoachがコードを評価する深さを定義し、どのクラスまたはパッケージを組み込んで、どれを除外するかも指定できます。アドバイス・タイプ、CodeCoachの深さおよび評価するパッケージまたはクラスは、IDEから直接選択するか、コマンドラインから選択できます。さらに、ソース自体にプラグマを直接挿入し、CodeCoachでコードをテストする方法を調整できます。
CodeCoachに可能なかぎり正確なデータを提供して、精度の高いアドバイスを得るには、CodeCoachの実行セッション中にコードの動作試験を十分に行うことが重要です。UIのすべてのメニューとボタンを使用し、すべてのケースを網羅してください。アプリケーションのすべての機能を実行してコード全体を実行しないと、CodeCoachが返すアドバイスによりアプリケーションのパフォーマンスが低下することがあります。
なぜコード全体を対象にする必要があるのでしょうか。VMのCodeCoachシステムでは、実際にロードされたクラスのみを検討できます。また、Javaは遅延ローディング言語であるため、クラスは参照されたときにではなく実際に使用される場合にのみロードされます。クラスが参照されたのみで使用されていない場合、CodeCoachにはそのクラスの存在を認識する方法がありません。返されるアドバイスを有効にするには、設計したプログラムで使用するすべてのクラスを、そのプログラムでロードする必要があります。
たとえば、次のコードがあるとします。
class Greeting {
String title;
String name;
public Greeting() {
}
public Greeting(String title, String name) {
this.title = title;
this.name = name;
}
public String toString() {
return "Hello " + title + " " + name;
}
}
class DearGreeting extends Greeting {
public DearGreeting(String name) {
this.title = "Dear";
this.name = name;
}
}
public class Class1 extends Object {
static Object getGreeting(String name, boolean isfemale) {
if (name.equals("Joe")) {
return new DearGreeting(name);
}
if (isfemale) {
return new Greeting("Mrs", name);
}
else {
return new Greeting("Mr", name);
}
}
public Class1() {
}
public static void main(String[] args) {
System.out.println(getGreeting("Kiks", false));
}
}
この単純なプログラムにCodeCoachを使用した場合、次のようなアドバイスが提供されます。
(CFIN) Class Greeting should be final
(CFIN) Class Class1 should be final
(FPRI) Field java.lang.String name should be private
(FPRI) Field java.lang.String title should be private
このアドバイスに従うと、コンパイルできません。DearGreeting
がGreeting
を拡張しているため、Greeting
はfinalにできません。また、DearGreeting
はjava.lang.String
にアクセスする必要があるため、このフィールドの名前もタイトルもprivateにできません。
では、なぜCodeCoachはこのように一見間違ったアドバイスを返すのでしょうか。 それは、getGreeting
メソッドが、Kiksを引数として1回のみコールされ、名前がJoeの場合のみDearGreeting
のインスタンスが返されるためです。 このためreturn new DearGreeting(name);
という行はこの実行では実行されず、Javaではクラスが実際に使用されるまでロードを待機するため、DearGreeting
クラスはこの実行中にロードされません。 DearGreeting
クラスが存在しない場合(また、このクラスが存在しないことをCodeCoachが認識しているかぎり)、返されるアドバイスは適切です。
一方、引数としてJoeが使用されている場所でgetGreeting
メソッドがコールされる場合、またはプログラムの他の部分でDearGreeting
クラスのインスタンスが使用されている場合は、CodeCoachシステムから次のアドバイスが生成されます。
(CFIN) Class DearGreeting should be final
(CFIN) Class Class1 should be final
これは非常に単純な例であり、実際のプログラムでは関係がはるかに複雑になります。このため、ロードされたクラスに対するこの依存性を念頭に置く必要があります。理想は、設計したプログラムで使用するすべてのクラスを、そのプログラムでCodeCoachの実行時にロードすることです。この理想に近づくほど、アドバイスが正確になります。
常に理想どおりに行うことは不可能なため、最初に評価してからCodeCoachアドバイスに従わないと、プログラムをコンパイルできなくなることがあります。この状況が発生した場合は、修正を取り消し、プラグマを使用して誤解を招くアドバイスを無視します。
コードが完全であるほど、CodeCoachのアドバイスが正確になります。一方、プログラムが完成するまで、あるいは完成間近まで待ってからCodeCoachを初めて実行すると、返されるメッセージ数が膨大になる可能性があります。
最善の方法は、プログラムの開発時にCodeCoachを常に使用し、作業中に提案を検討して、使用可および使用不可にするアドバイス・タイプを目的にあわせて判断できるようにすることです。ただし、CodeCoachを使用するプロセスの初期段階では、すべての設計が終了していないので、CodeCoachは設計の全体像を認識できないことを考慮する必要があります。たとえば、CodeCoachがメソッドをstaticで宣言するようアドバイスしても、そのメソッドを最終的にサブクラスでオーバーロードすることがわかっている場合は、このアドバイスを無視してもかまいません。プラグマまたはログ・ウィンドウのポップアップ・メニューを使用し、このアドバイスを使用不可にすることもできます。CodeCoachは参照したものしか考慮できないため、必要な訂正を提供する必要があります。
CodeCoachを上手に利用すれば、ツールとして非常に役立ち、時間も節約できます。ただし、CodeCoachのアドバイスに従う前に、意図しない結果を防ぐために全体像を考慮してください。
Copyright © 1997, 2004, Oracle. All rights reserved.