總結十個適用但偏執的Java編程技術

前言

當在沉溺於編碼一段時間當前（比方說我曾經投入近20年左右的時間在順序上了），你會漸漸對這些東西習以為常。由於，你知道的……任何事情有能夠出錯，沒錯，確實如此。

這就是為什麼我們要采用“進攻性編程”，即一些偏執習氣的緣由。上面是我團體以為的10個最有用但偏執的Java編程技術。一同來看一看吧：

一、將String字符串放在最後面

為了避免偶發性的NullPointerException 異常，我們通常將String放置在equals()函數的右邊來完成字符串比擬，如下代碼：

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

這是隨意用腦子想想就可以做的事，從Bad版本的代碼改寫表達式到Good版本的代碼，這兩頭並不會喪失任何東西。歡送不同的觀念…

二、不要置信晚期的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++) {
  ...
 }
 }
}

三、不要置信“-1”

我知道這是偏執的，但Javadoc中對 String.indexOf()辦法明白指出：對象內第一次呈現指定字符的地位索引，假如為-1則表示該字符不在字符序列中。

所以運用-1是天經地義的，對嗎？我說不對，請看以下代碼：

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

誰知道呢。也許到時分他們改動了編碼方式，對字符串並不區分大小寫，也許更好的方式是前往-2？誰知道呢。

四、防止不測賦值

是的。這種事情也許常常會發作。

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

所以你可以將比擬常量放置在左側，這樣就不會發作不測賦值的錯誤了。

五、反省Null和Length

無論如何，只需你有一個集合、數組等，請確保它存在，並且不為空。

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

你並不知道這些數組從哪裡來，也許是來自晚期版本的JDK API，誰知道呢。

六、一切的辦法都是final的

你也許會通知我你的開/閉准繩，但這都是胡言亂語。我不置信你（正確承繼我這個父類的一切子類），我也不置信我自己（不小心承繼我這個父類的一切子類）。所以關於那些意義明白的辦法要嚴厲用final標識。

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

七、一切變量和參數都是final

好像我說的。我不置信我自己（不要不測掩蓋我的值）。話雖如此，我不置信我自己的是由於…

…這就是為什麼一切的變量和參數都是final的緣由。

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

八、重載時不要置信泛型

是，它可以發作。你置信你寫的超級美觀的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);

置信我。這一切我都看到過。包括上面的

這種偏執還是不錯的。

九、總是在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時，將會呈現無法找到的提示，而不會讓人不知所謂。

十、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語句中的跳轉標志一樣。

總結

偏執編程看起來似乎不可思議，有時，由於代碼常常被證明是更詳細一點，但並不是需求需求。你能夠會想，“哦，這是絕不會發作的”，但正如我所說。經過20年左右的時間編程，你不希望只修復這些愚笨的bug，由於編程言語是如此的陳腐的和有缺陷的。由於你知道…

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或許任務能帶來一定的協助，假如有疑問大家可以留言交流。