為了防止偶發性的NullPointerException
異常,我們通常將String放置在equals()函數的左邊來實現字符串比較,如下代碼:
<pre http:="" www.ahlinux.com="" start="" cmd="" 9034.html"="" target="_blank" class="keylink">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++) { ... } } }
我知道這是偏執的,但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) { ... }
所以你可以將比較常量放置在左側,這樣就不會發生意外賦值的錯誤了。
無論如何,只要你有一個集合、數組等,請確保它存在,並且不為空。
// Bad if (array.length > 0) { ... } // Good if (array != null && array.length > 0) { ... }
你並不知道這些數組從哪裡來,也許是來自早期版本的JDK API,誰知道呢。
你也許會告訴我你的開/閉原則,但這都是胡說八道。我不相信你(正確繼承我這個父類的所有子類),我也不相信我自己(不小心繼承我這個父類的所有子類)。所以對於那些意義明確的方法要嚴格用final標識下載地址 。
// Bad public void boom() { ... } // Good. Don't touch. public final void dontTouch() { ... }
就像我說的。我不相信我自己(不要意外覆蓋我的值)。話雖如此,我不相信我自己的是因為…
…這就是為什麼所有的變量和參數都是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語句……它們其中一個可笑的語句我不知道該對它敬畏還是哭泣,但無論如何,既然我們堅持用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是最邪惡的語句,像是一些喝醉了或者賭輸了的人在寫代碼一樣,看下面的例子:
// 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語句中的跳轉標記一樣。