Java コードの典型的なエラー。

この資料には、私と協力している人々の Java コードで見た最も典型的なエラーが含まれています。静的解析 (ここではquliceを使用します) では、明らかな理由により、このようなエラーをすべて検出することはできません。そのため、ここでそれらのエラーをリストすることにしました。これらのエラーはすべて、オブジェクト指向プログラミング全般、特に Java に関連しています。

クラス名

あなたのクラスは、「バリデータ 」 、「コントローラ 」、 「マネージャ 」など を持たない現実のオブジェクトの抽象化である必要があります。クラス名が「-er」で終わる場合、それは悪い設計です。そしてもちろん、 Apache の StringUtils、 FileUtils、 IOUtilsなどのアンチパターン ヘルパー クラスは、ひどい設計パターンの良い例です。インターフェイスとクラスを区別するためにサフィックスやプレフィックスを追加しないでください。たとえば、 IRecord、 IfaceEmployee、または RecordInterfaceなどの名前はすべてひどいものです。通常、インターフェイス名は現実のオブジェクトの名前ですが、クラス名は実装の詳細を説明する必要があります。 実装に関して具体的なことが何も言えない場合は、「 Default」、「 Simple 」、またはそれに類似した名前で十分です。例えば： class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};

メソッド名

メソッドは「 something」または「 void」を返すことができます。メソッドが何かを返す場合、その名前で何が返されるかを説明する必要があります。例: (接頭辞「 get」は使用しないでください): 「 void boolean isValid(String name); String content(); int ageOf(File file); 」が返される 場合、そのメソッドの動作を名前で明確にする必要があります。例: このルールの例外は 1 つだけです - JUnitテスト メソッドです。それらについては以下で説明します。 void save(File file); void process(Work work); void append(File file, String line);

テストメソッド名

JUnit テストのメソッド名は、スペースを含まない英語の文として作成する必要があります。これは、例で説明するのが簡単です。JavaDoc /** * HttpRequest can return its content in Unicode. * @throws Exception If test fails */ public void returnsItsContentInUnicode() throws Exception { } の最初の文を、テストするクラスの名前で開始し、その後に「 can」を続けることが重要です。 したがって、最初の文は常に「誰かが何かをできる」というフレーズのようにする必要があります。メソッド名には同じことが記載されていますが、テストの主題は含まれていません。これをメソッド名の先頭に追加すると、上の例のような完全な英語の文が得られます。「 HttpRequest はそのコンテンツを unicode で返します。」 テストメソッド名が「 can 」で始まらないことに注意してください。JavaDoc コメントのみが「 can 」で始まります。さらに、メソッド名は動詞で始めるべきではありません ( 翻訳者より: 明らかに、著者は動詞の命令的なムードを意味しているようです)。テスト メソッドを宣言するときに、例外がスローされることを示すことをお勧めします。

変数名

timeOfDay、 firstItem、 httpRequestなど の複合変数名は避けてください。クラス変数とメソッド変数の両方を意味します。変数名は、スコープ内の曖昧さを避けるために十分な長さである必要がありますが、可能であれば長すぎないようにします。名前は単数名詞または複数名詞である必要があります。例: コンストラクターが作成されたオブジェクトに入力データを格納する場合、コンストラクターのパラメーターとクラス フィールドの間で衝突が発生することがあります。この場合、母音を削除して略語を作成することをお勧めします。例: ほとんどの場合、最適な変数名は、対応するクラスの名前になります。大文字にするだけで問題ありません。 ただし、や の ようなプリミティブ型に対しては、決して同じことをしないでください。異なる特性を持つ変数が複数ある場合は、形容詞を使用することもできます。例えば： List names; void sendThroughProxy(File file, Protocol proto); private File content; public HttpRequest request; public class Message { private String recipient; public Message(String rcpt) { this.recipient = rcpt; } } File file; User user; Branch branch; Integer number String string String contact(String left, String right);

コンストラクター

例外なく、データをオブジェクト変数に格納するコンストラクターは 1 つだけである必要があります。他のすべてのコンストラクターは、異なるパラメーターを使用してこれを呼び出す必要があります。 public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }

ワンタイム変数

1 回限りの変数は絶対に避けてください。「使い捨て」とは、一度だけ使用される変数を意味します。この例のように: String name = "data.txt"; return new File(name); 変数は 1 回だけ使用され、コードは次のように簡略化できます。 return new File("data.txt"); 非常にまれなケースですが、主に書式設定の改善により、1 回限りの変数が使用されることがあります。ただし、そのような状況は避けるようにしてください。

例外。

もちろん、例外を「飲み込む」ことは決してすべきではなく、例外は可能な限り高くスローされる必要があります。プライベート メソッドからの例外は外部で処理する必要があります。フローを制御するために例外を使用しないでください。この例のコードは間違っています。 int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; } 真面目な話、IOException で「ディスクがいっぱいです」と言われたら、ファイル サイズがゼロであると想定して続行しますか?

インデント。

インデントの場合、一般的な規則は、括弧が行を終了するか、同じ行で閉じなければならないということです (閉じ括弧には反対の規則が適用されます)。以下の例では、最初のかっこが同じ行で閉じられておらず、その後に文字があるため、コードは正しくありません。2 番目の括弧でも、その前に文字があり、現在の行に左括弧がないため、同じ問題が発生します。 final File file = new File(directory, "file.txt"); 正しいインデントは次のようになります。 StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" ); インデントの 2 番目に重要なルールは、できる限り 1 行に 80 文字以内で配置することです。上記の例は圧縮される可能性があるため無効です。 StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );

冗長な定数。

クラス定数は、クラス メソッド間で情報へのアクセスを共有する場合に使用する必要があり、この情報はクラスの特性 ( ! ) です。文字列や数値リテラルの代わりに定数を使用しないでください。非常に悪い習慣であり、コード汚染につながります。定数 (他の OOP オブジェクトと同様) は、現実世界では意味を持たなければなりません。現実の世界でのこれらの定数の意味は次のとおりです。 class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice } もう 1 つのよくある間違いは、テスト メソッドで文字列/数値リテラルの重複を避けるために単体テストで定数を使用することです。そんなことしたらダメ！各テスト メソッドは、独自の入力値のセットを操作する必要があります。新しいテスト方法ごとに新しいテキストと数値を使用します。テストは独立しています。では、なぜ同じ入力定数を共有する必要があるのでしょうか?

テストデータの結合。

テスト メソッドでのフックの例を次に示します User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff"))。 最後の行では、「 Jeff」を最初の行で指定した同じ文字列リテラルと連結します。数か月後、誰かが 3 行目の値を変更したい場合、このメソッド内で「 Jeff 」が他にどこで使用されているかを検索するために余分な時間を費やす必要があります。このデータの引っかかりを避けるには、変数を導入する必要があります。