這是一個(gè)國(guó)外大神20多年的經(jīng)驗(yàn)總結(jié)出來的……

　　“任何可能出錯(cuò)的事情，最后都會(huì)出錯(cuò)?！?/p>

　　這就是人們?yōu)槭裁聪矚g進(jìn)行“防錯(cuò)性程序設(shè)計(jì)”的原因。偏執(zhí)的習(xí)慣有時(shí)很有意義，有時(shí)則不夠清晰也不夠聰明，也許當(dāng)你想到這樣寫的人的時(shí)候還會(huì)覺得有點(diǎn)怪異。下面是我列出的的個(gè)人感覺最有用而又偏執(zhí)的 10 項(xiàng) Java 編程技巧。請(qǐng)看：

　　1. 把字符串常量放在前面

　　通過把字符串常量放在比較函數(shù)equals()比較項(xiàng)的左側(cè)來防止偶然的 NullPointerException 從來都不是一個(gè)壞主意，就像這樣：

　　這是毫無疑問的，把一種表達(dá)式轉(zhuǎn)換成另一種更好的表達(dá)式，并不會(huì)失去什么。只要我們的Options是真實(shí)存在的(Java 8中 Optional是對(duì)可以為空的對(duì)象進(jìn)行的封裝)，不是嗎?討論一下…

　　2. 不要相信早期的JDK APIs

　　Java剛出現(xiàn)的時(shí)候，編程一定是件很痛苦的事。那時(shí)的API仍然不夠成熟，你可能曾經(jīng)遇到過這樣一段代碼：

　　看起來很奇怪對(duì)嗎?也許吧，但是看看這個(gè)Javadoc：

　　“如果抽象路徑名表示的不是一個(gè)目錄，那么這個(gè)方法返回。否則返回一個(gè)字符串?dāng)?shù)組，其中每個(gè)字符串表示當(dāng)前目錄下的一個(gè)文件或目錄?！?/p>

　　是的，最好再加上判空檢查，以確保正確：

　　糟糕!前者違反了 Java 編碼中 10 個(gè)微妙的最佳實(shí)踐的規(guī)則#5和#6。因此一定要記得判 null檢查!

　　3. 不要相信“-1”

　　我知道這很偏執(zhí)，Javadoc中關(guān)于 String.indexOf() 的早期描述是這樣的:

　　“字符在字符序列中第一次出現(xiàn)的位置將作為結(jié)果[被返回]，如果字符不存在則返回-1?！?/p>

　　所以，-1 就可以理所當(dāng)然被拿來用，對(duì)嗎?我說不對(duì)，看看這個(gè)：

　　誰知道呢。也許在某個(gè)特定場(chǎng)合下他們將會(huì)需要另一種 編碼值，如果不區(qū)分大小寫的話，otherString 就會(huì)被包含進(jìn)去…此時(shí)或許可以返回 -2呢?誰知道呢。

　　畢竟，我們有非常多關(guān)于NULL——價(jià)值億萬美金的錯(cuò)誤的討論。為什么不開始討論 -1呢，某種意義上來說 -1 是 null 在int類型下的另一種形式。

　　4. 避免意外的賦值

　　是的。即使最優(yōu)秀的程序員也可能犯這種錯(cuò)誤(當(dāng)然，不包括我?？?7)。

　　(假設(shè)這是JavaScript，我們暫且偏執(zhí)地認(rèn)為是這種語言)

　　再說一遍。如果你的表達(dá)式中有常量，將它放在等式左邊。這樣當(dāng)你打算再添加一個(gè) = 時(shí)，不容易出錯(cuò)。

　　5. 檢查null和長(zhǎng)度

　　不管什么時(shí)候你有一個(gè)集合、數(shù)組或者其他的，確保它存在并且不為空。

　　你不知道這些數(shù)組來自哪兒，也許是早期的JDK API呢?

　　6. 所有的方法都用 final 聲明

　　你可以告訴我任何你想要的開閉原則，不過那都是胡說八道。我不相信你(可以正確繼承我的類)，也不相信我自己(不會(huì)意外地繼承我的類)。因此除了接口(專門用于繼承)都應(yīng)該是嚴(yán)格的 final。

　　是的，寫成final。如果這樣做對(duì)你來說沒有意義，你也可以通過修改或重寫字節(jié)碼來改變類和方法，或者發(fā)送功能請(qǐng)求。作為Java技術(shù)棧公眾號(hào)小編，我敢肯定的告訴你重寫類/方法并不是一個(gè)好主意。

　　7. 所有的變量和參數(shù)都用 final 聲明

　　就像我說的，我不相信自己不會(huì)無意間重寫了某個(gè)值。這么說來，我的確一點(diǎn)都不相信自己。因?yàn)椋?/p>

　　這也是為什么所有的變量和參數(shù)都用final聲明的原因。

　　好吧，我承認(rèn)，這一條我自己也不常用，雖然我應(yīng)該用。我希望Java能像Scala語言一樣，人們?cè)谒械胤蕉贾苯佑?val 來表示變量，甚至都不考慮易變性，除非明確需要的時(shí)候他們才用 var 來聲明變量，但是這樣的機(jī)會(huì)特別少。

　　8. 重載的時(shí)候不要相信泛型

　　是的，這是會(huì)發(fā)生的。你覺得你寫了一個(gè)超好的API，它真的是既酷炫又直觀;接著就出現(xiàn)了一群用戶，他們只是把一切類型生搬硬套進(jìn) Object 中 直到那該死的編譯器停止工作，然后他們突然鏈接到了錯(cuò)誤的方法，認(rèn)為這一切都是你的錯(cuò)(事情總是這樣)。

　　思考一下這個(gè)：

　　因?yàn)?，你知道的…你的用戶們，他們就像這樣

　　相信我，我看過的多了，還有這樣的

　　所以說偏執(zhí)是有好處的。

　　9. 總是在switch語句里加上default

　　Switch…作為最滑稽的表達(dá)式之一，我不知道是該心存敬畏還是默默哭泣。不管怎樣，我們既然無法擺脫 switch ，在必要的時(shí)候我們最好能夠正確使用它，例如：

　　因?yàn)樵诋?dāng) value=3 被引入到軟件中的時(shí)候，default 就能發(fā)揮作用，使其正常運(yùn)行!別和我提 enum 類型，因?yàn)檫@對(duì) enums 也一樣適用。

　　10. 用大括號(hào)隔開 switch 的每一個(gè) case 塊

　　事實(shí)上，switch是最坑爹的語句，任何喝醉了或是賭輸了的人都可以在某種語言中使用它?？纯聪旅孢@個(gè)例子：

　　在switch語句中，為所有的case都只定義了一個(gè)作用域。事實(shí)上，這些case不是真正意義上的語句，他們更像是標(biāo)簽，而switch就是指向這些標(biāo)簽的goto語句。事實(shí)上，你甚至可以把case語句和 驚人的FORTRAN77項(xiàng)聲明 類比，對(duì)于FORTRAN，它的神秘已經(jīng)超越了它的功能。

　　這意味著變量final int j 可以被任何case訪問，不論我們是否有break?？雌饋聿⒉皇呛苤庇^。我們可以通過添加簡(jiǎn)單的花括號(hào)為每一個(gè)case創(chuàng)建一個(gè)新的嵌套的作用域，當(dāng)然不要忘了在每個(gè) case 的語句塊最后加 break。

　　結(jié)論

　　編程時(shí)的強(qiáng)迫癥有時(shí)候看起來會(huì)很奇怪，會(huì)使得代碼往往比必需的還要冗長(zhǎng)。你可能會(huì)想，“啊，這種情況永遠(yuǎn)不會(huì)發(fā)生!”，但是正如我所說的，在經(jīng)歷了20年左右的編程生涯后，你不會(huì)想要再去修正那些只是因?yàn)榫幊陶Z言的古老和固有缺陷而導(dǎo)致的愚蠢而不必要的bug了。因?yàn)槟阒馈?.

　　Now，輪到你了!