実践的だが偏執的な Java プログラミング テクニック 10 選

一定期間コーディングに没頭すると、徐々にこれらのことに慣れてきます。なぜなら、ご存知の通り...

何かがうまくいかない可能性はあります、はい、それは起こります。

これが私たちが「防御的なプログラミング」を採用する理由であり、それが一部の偏執的な習慣の原因です。以下は、私が個人的に考える、最も便利だが偏執的な Java プログラミング テクニック 10 個です。見てみましょう:

1. String 文字列を先頭に置きます

時折発生する NullPointerException 例外を防ぐために、通常、文字列比較を実装するために、equals() 関数の左側に String を置きます。 code:

// Bad
if (variable.equals("literal")) { ... }
// Good
if ("literal".equals(variable)) { ... }

これは、悪いバージョンのコードから良いバージョンのコードに式を書き換えるまで、考えるだけで実行できるものであり、その過程で何も失われることはありません。さまざまな意見を歓迎します...

2. 初期の JDK API を信頼しないでください

Java の初期の頃、プログラミングは非常に苦痛なものでした。これらの API はまだ非常に未熟なので、次のコード ブロックに遭遇したことがあるかもしれません:

String[] files = file.list();
// Watch out
if (files != null) {
    for (int i = 0; i < files.length; i++) {
        ...
    }
}

偏執的に見えますか?おそらくですが、Javadoc を参照してください:

この仮想パスがフォルダー ディレクトリを表さない場合、このメソッドは null を返します。それ以外の場合は、文字列の配列が返され、各文字列はディレクトリ内のファイルまたはフォルダーを表します。

はい、そうです。いくつかの検証を追加できます:

if (file.isDirectory()) {
    String[] files = file.list();
    // Watch out
    if (files != null) {
        for (int i = 0; i < files.length; i++) {
            ...
        }
    }
}

3. 「-1」を信じないでください

これが偏執的であることは承知していますが、Javadoc では String.indexOf() メソッド、つまり指定された文字列が最初に出現する位置を明確に指摘しています。オブジェクト Index 内の文字が -1 の場合、その文字は文字シーケンスに含まれていないことを意味します。

つまり、-1 を使用するのは簡単ですよね?よくわかりません。次のコードを見てください:

// Bad
if (string.indexOf(character) != -1) { ... }
// Good
if (string.indexOf(character) >= 0) { ... }

誰にもわかりません。おそらくその頃には文字列が大文字と小文字を区別しないようにエンコーディングが変更されており、おそらく -2 を返す方が良い方法なのではないでしょうか?知るか。

4. 誤った割り当てを避ける

はい。これは頻繁に起こるかもしれません。

// Ooops
if (variable = 5) { ... }
// Better (because causes an error)
if (5 = variable) { ... }
// Intent (remember. Paranoid JavaScript: ===)
if (5 === variable) { ... }

ということで、比較定数を左側に置くことで、偶発的な代入エラーが発生しないようにすることができます。

5. Null と Length を確認する

コレクションや配列などがある限り、それが存在し、空でないことを確認してください。

// Bad
if (array.length > 0) { ... }
// Good
if (array != null && array.length > 0) { ... }

これらの配列がどこから来たのか、おそらく以前のバージョンの JDK API から来たのかはわかりません。

6. すべてのメソッドは最終的なものです

オープン/クローズの原則を教えてくれるかもしれませんが、これはすべてナンセンスです。私はあなた (私の親クラスのすべてのサブクラスを正しく継承する) を信じませんし、私自身 (誤って私の親クラスのすべてのサブクラスを継承する) も信じません。したがって、明確な意味を持つメソッドには、厳密に Final マークを付ける必要があります。

// Bad
public void boom() { ... }
// Good. Don't touch.
public final void dontTouch() { ... }

7. すべての変数とパラメータは最終的なものです

私が言ったように。私は自分自身を信頼していません（誤って自分の価値観を上書きしないように）。そうは言っても、私は自分の意見を信じていないので…

…这就是为什么所有的变量和参数都是final的原因。

// Bad
void input(String importantMessage) {
   String answer = "...";
   answer = importantMessage = "LOL accident";
}
// Good
final void input(final String importantMessage) {
   final String answer = "...";
}

8.重载时不要相信泛型

　　是，它可以发生。你相信你写的超级好看的API，它很直观，随之而来的，一些用户谁只是将原始类型转换成Object类型，直到那该死的编译器停止发牢骚，并且突然他们会链接错误的方法，以为这是你的错误。

　　看下面的代码：

// Bad
<T> void bad(T value) {
    bad(Collections.singletonList(value));
}
<T> void bad(List<T> values) {
    ...
}
// Good
final <T> void good(final T value) {
    if (value instanceof List)
        good((List<?>) value);
    else
        good(Collections.singletonList(value));
}
final <T> void good(final List<T> values) {
    ...
}

因为，你知道……你的用户，他们就像

// This library sucks
@SuppressWarnings("all")
Object t = (Object) (List) Arrays.asList("abc");
bad(t);

　　相信我。这一切我都看到过。包括下面的

这种偏执还是不错的。

　9.总是在Switch语句的Default中抛出异常

　　Switch语句……它们其中一个可笑的语句我不知道该对它敬畏还是哭泣，但无论如何，既然我们坚持用switch，那我们不妨将它用得完美，看下面的代码：

// Bad
switch (value) {
    case 1: foo(); break;
    case 2: bar(); break;
}
// Good
switch (value) {
    case 1: foo(); break;
    case 2: bar(); break;
    default:
        throw new ThreadDeath("That'll teach them");
}

　　当value == 3时，将会出现无法找到的提示，而不会让人不知所谓。

　10.Switch语句带花括号

　　事实上，switch是最邪恶的语句，像是一些喝醉了或者赌输了的人在写代码一样，看下面的例子：

// Bad, doesn't compile
switch (value) {
    case 1: int j = 1; break;
    case 2: int j = 2; break;
}
// Good
switch (value) {
    case 1: {
        final int j = 1;
        break;
    }
    case 2: {
        final int j = 2;
        break;
    }
    // Remember:
    default: 
        throw new ThreadDeath("That'll teach them");
}

　　在switch语句中，每一个case语句的范围只有一行语句，事实上，这些case语句甚至不是真正的语句，他们就像goto语句中的跳转标记一样。

在switch语句中，每一个case语句的范围只有一行语句，事实上，这些case语句甚至不是真正的语句，他们就像goto语句中的跳转标记一样。

　结论

　　偏执编程看起来似乎不可思议，有时，因为代码经常被证明是更详细一点，但并不是需求需要。你可能会想，“哦，这是绝不会发生的”，但正如我所说。经过20年左右的时间编程，你不希望只修复这些愚蠢的bug，因为编程语言是如此的陈旧的和有缺陷的。因为你知道…