經過一段時間的編碼（以我為例，大約20年左右，當您玩得開心時光飛逝），人們開始接受這些習慣。 因為，你知道...

任何可能出錯的事情都會發生。

這就是為什么人們會采用“防御性編程”的原因，即偏執狂的習慣有時會變得很有意義，有時會變得晦澀難懂和/或聰明，甚至當您想到編寫它的人時也會有些怪異。 這是我個人列出的十大有用但又偏執的Java編程技術。 我們走吧：

1.首先將字符串文字

通過將String文字放在equals()比較的左側，來防止偶發的NullPointerException從來不是一個壞主意，如下所示：

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

這很容易。 將表述從不太好的版本改寫為更好的版本并不會丟失任何內容。 如果我們只有真正的期權 ，對嗎？ 不同的討論…

2.不要相信早期的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 outif (files != null) {for (int i = 0; i < files.length; i++) {...}} }

mm！ 編碼Java列表時，違反了我們的10條最佳最佳實踐中的規則5和6。 因此，請做好準備并添加該null檢查！

3.不要相信“ -1”

我知道這很偏執。 String.indexOf()的Javadoc明確指出……

返回此對象表示的字符序列中字符首次出現的索引（如果沒有出現，則返回-1）。

因此， -1是理所當然的，對吧？ 我說不。 考慮一下：

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

誰知道。 也許他們需要在某個時間點進行ANOTHER編碼，以便說，如果不區分大小寫地檢查， otherString包含otherString ……也許是返回-2的好例子？ 誰知道。

畢竟， 關于十億美元的錯誤 ，我們已經進行了數十億次討論，這是NULL 。 為什么我們不應該開始討論-1 ，它在某種程度上是原始類型int的替代null ？

4.避免意外分配

是的 它發生的最好（盡管不是我。請參閱＃7）。

（假設這是JavaScript，但是我們也要對語言保持偏執）

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

再次。 如果您的表達式中有文字，請將其放在左側。 當您打算添加另一個=符號時，您不會在這里偶然出錯。

5.檢查空AND長度

只要有集合，數組等，請確保其存在且不為空。

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

您永遠不知道這些數組從何而來。 也許來自早期的JDK API？

6.所有方法均為最終方法

您可以告訴我所有關于您的開放/封閉原則的信息，這些都是胡扯。 我不信任您（正確地擴展了我的課程），我也不信任自己（不偶然地擴展了我的課程）。 這就是為什么所有未明確打算用于子類型化的東西（即僅接口）都是final 。 另請參閱我們的《 編碼Java的10個最佳最佳實踐》列表中的第9條。

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

是。 這是最終的。 如果那對您不起作用，請對其進行修補或檢測，或重寫字節碼。 或發送功能請求。 我敢肯定，您要覆蓋上述內容并不是一個好主意。

7.所有變量和參數均為最終變量

就像我說的。 我不信任自己（不會意外覆蓋我的價值觀）。 話雖如此，我一點也不相信自己。 因為…

…這就是為什么所有變量和參數也都設為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.重載時不要相信泛型

是。 這有可能發生。 您相信您寫的是一個超級棒的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);elsegood(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);

相信我。 我已經看到了一切。 包括像

偏執是很好的。

9.始終打開默認開關

切換...這些滑稽的陳述之一，我不知道該敬畏地嚇呆還是哭泣。 無論如何，我們被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引入軟件的那一刻，它一定會來！ 不要說enum ，因為它會發生在enums的！

10.用花括號切換

實際上， 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語句與令人驚訝的FORTRAN 77 ENTRY語句進行比較， FORTRAN 77 ENTRY語句的神秘之處僅在于其強大功能。

這意味著變量final int j是針對所有不同情況定義的，無論我們是否發出break 。 不是很直觀。 這就是為什么通過一個簡單的block為每個case語句創建一個新的嵌套作用域始終是一個好主意的原因。 （但不要忘記塊內的break ！）

結論

有時偏執狂的編程似乎很奇怪，因為代碼常常比實際需要的更為冗長。 您可能會想，“哦，這永遠不會發生”，但是正如我所說。 經過20年左右的編程，您只是不想修復僅由于該語言太老和有缺陷而不再存在的那些愚蠢的，不必要的小錯誤。 因為你知道

現在輪到你了！

您在編程中最偏執的怪癖是什么？

翻譯自: https://www.javacodegeeks.com/2015/08/top-10-useful-yet-paranoid-java-programming-techniques.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的十大有用但又偏执的Java编程技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。