經(jīng)過一段時間的編碼（咦，我已經(jīng)經(jīng)歷了將近20年的編程生涯枝缔，快樂的日子總是過得很快）布疙，我們開始感謝那些好習慣。因為愿卸，你知道…
“任何可能出錯的事情灵临，最后都會出錯∨枯”
這就是人們?yōu)槭裁聪矚g進行“防錯性程序設計”的原因儒溉。偏執(zhí)的習慣有時很有意義，有時則不夠清晰也不夠聰明发钝，也許當你想到這樣寫的人的時候還會覺得有點怪異顿涣。下面是我列出的的個人感覺最有用而又偏執(zhí)的 10 項 Java 編程技巧。請看：
1. 把字符串常量放在前面
通過把字符串常量放在比較函數(shù)equals()比較項的左側(cè)來防止偶然的 NullPointerException 從來都不是一個壞主意酝豪，就像這樣：
// Bad
if (variable.equals("literal")) { ... }
// Good
if ("literal".equals(variable)) { ... }
這是毫無疑問的涛碑，把一種表達式轉(zhuǎn)換成另一種更好的表達式，并不會失去什么孵淘。只要我們的Options是真實存在的（Java 8中 Optional是對可以為空的對象進行的封裝）蒲障，不是嗎？討論一下…
2. 不要相信早期的JDK APIs
Java剛出現(xiàn)的時候瘫证，編程一定是件很痛苦的事揉阎。那時的API仍然不夠成熟，你可能曾經(jīng)遇到過這樣一段代碼：
String[] files = file.list();
// Watch out
if (files != null) {
? ?for (int i = 0; i < files.length; i++) {
? ? ? ?...
? ?}
}
看起來很奇怪對嗎背捌？也許吧毙籽，但是看看這個Javadoc：
“如果抽象路徑名表示的不是一個目錄，那么這個方法返回null毡庆。否則返回一個字符串數(shù)組坑赡，其中每個字符串表示當前目錄下的一個文件或目錄巡扇。”
是的垮衷，最好再加上判空檢查，以確保正確：
if (file.isDirectory()) {
? ?String[] files = file.list();
? ?// Watch out
? ?if (files != null) {
? ? ? ?for (int i = 0; i < files.length; i++) {
? ? ? ? ? ?...
? ? ? ?}
? ?}
}
糟糕乖坠！前者違反了 Java 編碼中 10 個微妙的最佳實踐 的規(guī)則＃5和＃6搀突。因此一定要記得判 null檢查！
3. 不要相信“-1”
我知道這很偏執(zhí)熊泵，Javadoc中關于 String.indexOf() 的早期描述是這樣的…
“字符在字符序列中第一次出現(xiàn)的位置將作為結(jié)果[被返回]仰迁，如果字符不存在則返回-1⊥绶郑”
所以徐许，-1 就可以理所當然被拿來用，對嗎卒蘸？我說不對雌隅，看看這個：
// Bad
if (string.indexOf(character) != -1) { ... }
// Good
if (string.indexOf(character) >= 0) { ... }
誰知道呢。也許在某個特定場合下他們將會需要另一種 編碼值缸沃，如果不區(qū)分大小寫的話恰起，otherString 就會被包含進去…此時或許可以返回 -2呢？誰知道呢趾牧。
畢竟检盼，我們有非常多關于NULL——價值億萬美金的錯誤的討論。為什么不開始討論 -1呢翘单，某種意義上來說 -1 是 null 在int類型下的另一種形式吨枉。
4. 避免意外的賦值
是的。即使最優(yōu)秀的程序員也可能犯這種錯誤（當然哄芜，不包括我貌亭。看#7）忠烛。
（假設這是JavaScript属提，我們暫且偏執(zhí)地認為是這種語言）
// Ooops
if (variable = 5) { ... }
// Better (because causes an error)
if (5 = variable) { ... }
// Intent (remember. Paranoid JavaScript: ===)
if (5 === variable) { ... }
再說一遍。如果你的表達式中有常量美尸，將它放在等式左邊冤议。這樣當你打算再添加一個 = 時，不容易出錯师坎。
5. 檢查null和長度
不管什么時候你有一個集合恕酸、數(shù)組或者其他的，確保它存在并且不為空胯陋。
// Bad
if (array.length > 0) { ... }
// Good
if (array != null && array.length > 0) { ... }
你不知道這些數(shù)組來自哪兒蕊温，也許是早期的JDK API呢袱箱？
6. 所有的方法都用 final 聲明
你可以告訴我任何你想要的開閉原則，不過那都是胡說八道义矛。我不相信你（可以正確繼承我的類）发笔，也不相信我自己（不會意外地繼承我的類）。因此除了接口（專門用于繼承）都應該是嚴格的 final凉翻×颂郑可以查看我們的 Java 編碼中 10 個微妙的最佳實踐 中的#9。
// Bad
public void boom() { ... }
// Good. Don't touch.
public final void dontTouch() { ... }
是的制轰，寫成final前计。如果這樣做對你來說沒有意義，你也可以通過修改或重寫字節(jié)碼來改變類和方法垃杖，或者發(fā)送功能請求男杈。我敢肯定重寫類/方法并不是一個好主意。
7. 所有的變量和參數(shù)都用 final 聲明
就像我說的调俘。我不相信自己不會無意間重寫了某個值伶棒。這么說來，我的確一點都不相信自己脉漏。因為：
這也是為什么所有的變量和參數(shù)都用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. 重載的時候不要相信泛型
是的，這是會發(fā)生的繁扎。你覺得你寫了一個超好的API幔荒，它真的是既酷炫又直觀；接著就出現(xiàn)了一群用戶梳玫，他們只是把一切類型生搬硬套進 Object 中 直到那該死的編譯器停止工作爹梁，然后他們突然鏈接到了錯誤的方法，認為這一切都是你的錯（事情總是這樣）提澎。
思考一下這個：
// Bad
void bad(T value) {
? ?bad(Collections.singletonList(value));
}
void bad(List values) {
? ?...
}
// Good
final ?void good(final T value) {
? ?if (value instanceof List)
? ? ? ?good((List) value);
? ?else
? ? ? ?good(Collections.singletonList(value));
}
final ?void good(final List values) {
? ?...
}
因為姚垃，你知道的…你的用戶們，他們就像這樣
// This library sucks
@SuppressWarnings("all")
Object t = (Object) (List) Arrays.asList("abc");
bad(t);
相信我盼忌，我看過的多了积糯，還有這樣的
所以說偏執(zhí)是有好處的掂墓。
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 就能發(fā)揮作用，使其正常運行窘游！別和我提 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八毯，它的神秘已經(jīng)超越了它的功能。
這意味著變量final int j 可以被任何case訪問瞄桨，不論我們是否有break话速。看起來并不是很直觀芯侥。我們可以通過添加簡單的花括號為每一個case創(chuàng)建一個新的嵌套的作用域泊交，當然不要忘了在每個 case 的語句塊最后加 break。
結(jié)論
編程時的強迫癥有時候看起來會很奇怪柱查，會使得代碼往往比必需的還要冗長廓俭。你可能會想，“啊物赶，這種情況永遠不會發(fā)生白指！”，但是正如我所說的酵紫，在經(jīng)歷了20年左右的編程生涯后告嘲，你不會想要再去修正那些只是因為編程語言的古老和固有缺陷而導致的愚蠢而不必要的bug了错维。因為你知道…..
