偏執卻管用的10條Java程式設計技巧

　　經過一段時間的編碼（咦，我已經經歷了將近20年的程式設計生涯，快樂的日子總是過得很快），我們開始感謝那些好習慣。因為，你知道…

　　“任何可能出錯的事情，最後都會出錯。”

　　這就是人們為什麼喜歡進行“防錯性程式設計”的原因。偏執的習慣有時很有意義，有時則不夠清晰也不夠聰明，也許當你想到這樣寫的人的時候還會覺得有點怪異。下面是我列出的的個人感覺最有用而又偏執的 10 項 Java 程式設計技巧。請看：

　1. 把字串常量放在前面

　　通過把字串常量放在比較函式equals()比較項的左側來防止偶然的 NullPointerException 從來都不是一個壞主意，就像這樣：

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

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

　　這是毫無疑問的，把一種表示式轉換成另一種更好的表示式，並不會失去什麼。只要我們的Options是真實存在的（Java 8中 Optional是對可以為空的物件進行的封裝），不是嗎？討論一下…

　2. 不要相信早期的JDK APIs

　　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++) {
            ...
        }
    }
}

　　糟糕！前者違反了 Java 編碼中 10 個微妙的最佳實踐 的規則＃5和＃6。因此一定要記得判 null檢查！

　3. 不要相信“-1”

　　我知道這很偏執，Javadoc中關於 String.indexOf() 的早期描述是這樣的…

　　“字元在字元序列中第一次出現的位置將作為結果[被返回]，如果字元不存在則返回-1。”

　　所以，-1 就可以理所當然被拿來用，對嗎？我說不對，看看這個：

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

// Good
if (string.indexOf(character) >= 0) { ... }

　　誰知道呢。也許在某個特定場合下他們將會需要另一種 編碼值，如果不區分大小寫的話，otherString 就會被包含進去…此時或許可以返回 -2呢？誰知道呢。

　　畢竟，我們有非常多關於NULL——價值億萬美金的錯誤的討論。為什麼不開始討論 -1呢，某種意義上來說 -1 是 null 在int型別下的另一種形式。

　4. 避免意外的賦值

　　是的。即使最優秀的程式設計師也可能犯這種錯誤（當然，不包括我。看#7）。

　　（假設這是JavaScript，我們暫且偏執地認為是這種語言）

// Ooops
if (variable = 5) { ... }

// Better (because causes an error)
if (5 = variable) { ... }

// Intent (remember. Paranoid JavaScript: ===)
if (5 === variable) { ... }

　　再說一遍。如果你的表示式中有常量，將它放在等式左邊。這樣當你打算再新增一個 = 時，不容易出錯。

　5. 檢查null和長度

　　不管什麼時候你有一個集合、陣列或者其他的，確保它存在並且不為空。

// Bad
if (array.length > 0) { ... }

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

　　你不知道這些陣列來自哪兒，也許是早期的JDK API呢？

　6. 所有的方法都用 final 宣告

　　你可以告訴我任何你想要的開閉原則，不過那都是胡說八道。我不相信你（可以正確繼承我的類），也不相信我自己（不會意外地繼承我的類）。因此除了介面（專門用於繼承）都應該是嚴格的 final。可以檢視我們的 Java 編碼中 10 個微妙的最佳實踐 中的#9。

// Bad
public void boom() { ... }

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

　　是的，寫成final。如果這樣做對你來說沒有意義，你也可以通過修改或重寫位元組碼來改變類和方法，或者傳送功能請求。我敢肯定重寫類/方法並不是一個好主意。

　7. 所有的變數和引數都用 final 宣告

　　就像我說的。我不相信自己不會無意間重寫了某個值。這麼說來，我的確一點都不相信自己。因為：

　　這也是為什麼所有的變數和引數都用final宣告的原因。

// Bad
void input(String importantMessage) {
    String answer = "...";

    answer = importantMessage = "LOL accident";
}

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

　　好吧，我承認，這一條我自己也不常用，雖然我應該用。我希望Java能像Scala語言一樣，人們在所有地方都直接用 val 來表示變數，甚至都不考慮易變性，除非明確需要的時候他們才用 var 來宣告變數，但是這樣的機會特別少。

　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 被引入到軟體中的時候，default 就能發揮作用，使其正常執行！別和我提 enum 型別，因為這對 enums 也一樣適用。

　10. 用大括號隔開 switch 的每一個 case 塊

　　事實上，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不是真正意義上的語句，他們更像是標籤，而switch就是指向這些標籤的goto語句。事實上，你甚至可以把case語句和 驚人的FORTRAN77項宣告 類比，對於FORTRAN，它的神祕已經超越了它的功能。

　　這意味著變數final int j 可以被任何case訪問，不論我們是否有break。看起來並不是很直觀。我們可以通過新增簡單的花括號為每一個case建立一個新的巢狀的作用域，當然不要忘了在每個 case 的語句塊最後加 break。

　結論

　　程式設計時的強迫症有時候看起來會很奇怪，會使得程式碼往往比必需的還要冗長。你可能會想，“啊，這種情況永遠不會發生！”，但是正如我所說的，在經歷了20年左右的程式設計生涯後，你不會想要再去修正那些只是因為程式語言的古老和固有缺陷而導致的愚蠢而不必要的bug了。因為你知道…..

　　https://youtu.be/oO3YmT2d-8k

　現在，輪到你了！

　　你在程式設計時有哪些強迫症呢？

　　原文連結： javacodegeeks 翻譯： ImportNew