這是一個國外大神20多年的經驗總結出來的……
“任何可能出錯的事情，最后都會出錯，”
這就是人們為什么喜歡進行“防錯性程式設計”的原因，偏執的習慣有時很有意義，有時則不夠清晰也不夠聰明，也許當你想到這樣寫的人的時候還會覺得有點怪異，下面是我列出的的個人感覺最有用而又偏執的 10 項 Java 編程技巧，請看：
1. 把字串常量放在前面
通過把字串常量放在比較函式equals()比較項的左側來防止偶然的 NullPointerException 從來都不是一個壞主意，就像這樣：
這是毫無疑問的，把一種運算式轉換成另一種更好的運算式，并不會失去什么，只要我們的Options是真實存在的（Java 8中 Optional是對可以為空的物件進行的封裝），不是嗎？討論一下…
2. 不要相信早期的JDK APIs
Java剛出現的時候，編程一定是件很痛苦的事，那時的API仍然不夠成熟，你可能曾經遇到過這樣一段代碼：
看起來很奇怪對嗎？也許吧，但是看看這個Javadoc：
“如果抽象路徑名表示的不是一個目錄，那么這個方法回傳null，否則回傳一個字串陣列，其中每個字串表示當前目錄下的一個檔案或目錄，”
是的，最好再加上判空檢查，以確保正確：
糟糕！前者違反了 Java 編碼中 10 個微妙的最佳實踐的規則＃5和＃6，因此一定要記得判 null檢查！
3. 不要相信“-1”
我知道這很偏執，Javadoc中關于 String.indexOf() 的早期描述是這樣的:
“字符在字符序列中第一次出現的位置將作為結果[被回傳]，如果字符不存在則回傳-1，”
所以，-1 就可以理所當然被拿來用，對嗎？我說不對，看看這個：
誰知道呢，也許在某個特定場合下他們將會需要另一種 編碼值，如果不區分大小寫的話，otherString 就會被包含進去…此時或許可以回傳 -2呢？誰知道呢，
畢竟，我們有非常多關于NULL——價值億萬美金的錯誤的討論，為什么不開始討論 -1呢，某種意義上來說 -1 是 null 在int型別下的另一種形式，
4. 避免意外的賦值
是的，即使最優秀的程式員也可能犯這種錯誤（當然，不包括我，看#7），
（假設這是JavaScript，我們暫且偏執地認為是這種語言）
再說一遍，如果你的運算式中有常量，將它放在等式左邊，這樣當你打算再添加一個 = 時，不容易出錯，
5. 檢查null和長度
不管什么時候你有一個集合、陣列或者其他的，確保它存在并且不為空，
你不知道這些陣列來自哪兒，也許是早期的JDK API呢？
6. 所有的方法都用 final 宣告
你可以告訴我任何你想要的開閉原則，不過那都是胡說八道，我不相信你（可以正確繼承我的類），也不相信我自己（不會意外地繼承我的類），因此除了介面（專門用于繼承）都應該是嚴格的 final，
是的，寫成final，如果這樣做對你來說沒有意義，你也可以通過修改或重寫位元組碼來改變類和方法，或者發送功能請求，作為Java技術堆疊公眾號小編，我敢肯定的告訴你重寫類/方法并不是一個好主意，
7. 所有的變數和引數都用 final 宣告
就像我說的，我不相信自己不會無意間重寫了某個值，這么說來，我的確一點都不相信自己，因為：
這也是為什么所有的變數和引數都用final宣告的原因，
好吧，我承認，這一條我自己也不常用，雖然我應該用，我希望Java能像Scala語言一樣，人們在所有地方都直接用 val 來表示變數，甚至都不考慮易變性，除非明確需要的時候他們才用 var 來宣告變數，但是這樣的機會特別少，
8. 多載的時候不要相信泛型
是的，這是會發生的，你覺得你寫了一個超好的API，它真的是既酷炫又直觀；接著就出現了一群用戶，他們只是把一切型別生搬硬套進 Object 中 直到那該死的編譯器停止作業，然后他們突然鏈接到了錯誤的方法，認為這一切都是你的錯（事情總是這樣），
思考一下這個：
因為，你知道的…你的用戶們，他們就像這樣
相信我，我看過的多了，還有這樣的
所以說偏執是有好處的，
9. 總是在switch陳述句里加上default
Switch…作為最滑稽的運算式之一，我不知道是該心存敬畏還是默默哭泣，不管怎樣，我們既然無法擺脫 switch ，在必要的時候我們最好能夠正確使用它，例如：
因為在當 value=https://www.cnblogs.com/javastack/p/3 被引入到軟體中的時候，default 就能發揮作用，使其正常運行！別和我提 enum 型別，因為這對 enums 也一樣適用，
10. 用大括號隔開 switch 的每一個 case 塊
事實上，switch是最坑爹的陳述句，任何喝醉了或是賭輸了的人都可以在某種語言中使用它，看看下面這個例子：
在switch陳述句中，為所有的case都只定義了一個作用域，事實上，這些case不是真正意義上的陳述句，他們更像是標簽，而switch就是指向這些標簽的goto陳述句，事實上，你甚至可以把case陳述句和 驚人的FORTRAN77項宣告 類比，對于FORTRAN，它的神秘已經超越了它的功能，
這意味著變數final int j 可以被任何case訪問，不論我們是否有break，看起來并不是很直觀，我們可以通過添加簡單的花括號為每一個case創建一個新的嵌套的作用域，當然不要忘了在每個 case 的陳述句塊最后加 break，
結論
編程時的強迫癥有時候看起來會很奇怪，會使得代碼往往比必需的還要冗長，你可能會想，“啊，這種情況永遠不會發生！”，但是正如我所說的，在經歷了20年左右的編程生涯后，你不會想要再去修正那些只是因為編程語言的古老和固有缺陷而導致的愚蠢而不必要的bug了，因為你知道…..
現在，輪到你了！
原文： http://www.javacodegeeks.com/2015/08/top-10-useful-yet-paranoid-java-programming-techniques.html
譯文： http：//www.importnew.com/16805.html
推薦去我的博客閱讀更多：
1.Java JVM、集合、多執行緒、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、后端、架構、阿里巴巴等大廠最新面試題
覺得不錯，別忘了點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/227057.html
標籤：Java
上一篇：HashMap：源代碼（構造方法、put、resize、get、remove、replace）
下一篇：DDD之3物體和值物件