通過一段時間的編碼（咦，我已經經歷了將近20年的編程生涯，快樂的日子老是過得很快），咱們開始感謝那些好習慣。由於，你知道…html
「任何可能出錯的事情，最後都會出錯。」java
這就是人們爲何喜歡進行「防錯性程序設計」的緣由。偏執的習慣有時頗有意義，有時則不夠清晰也不夠聰明，也許當你想到這樣寫的人的時候還會以爲有點怪異。下面是我列出的的我的感受最有用而又偏執的 10 項 Java 編程技巧。請看：程序員
1. 把字符串常量放在前面
經過把字符串常量放在比較函數equals()比較項的左側來防止偶然的 NullPointerException 歷來都不是一個壞主意，就像這樣：編程
|
1
2
3
4
5
|
// Bad
if
(variable.equals(
"literal"
)) { ... }
// Good
if
(
"literal"
.equals(variable)) { ... }
|
這是毫無疑問的，把一種表達式轉換成另外一種更好的表達式，並不會失去什麼。只要咱們的Options是真實存在的（Java 8中 Optional是對能夠爲空的對象進行的封裝），不是嗎？討論一下…api
2. 不要相信早期的JDK APIs
Java剛出現的時候，編程必定是件很痛苦的事。那時的API仍然不夠成熟，你可能曾經遇到過這樣一段代碼：數組
|
1
2
3
4
5
6
7
8
|
String[] files = file.list();
// Watch out
if
(files !=
null
) {
for
(
int
i =
0
; i < files.length; i++) {
...
}
}
|
看起來很奇怪對嗎？也許吧，可是看看這個Javadoc：oracle
「若是抽象路徑名錶示的不是一個目錄，那麼這個方法返回null。不然返回一個字符串數組，其中每一個字符串表示當前目錄下的一個文件或目錄。」編程語言
是的，最好再加上判空檢查，以確保正確：ide
|
1
2
3
4
5
6
7
8
9
10
|
if
(file.isDirectory()) {
String[] files = file.list();
// Watch out
if
(files !=
null
) {
for
(
int
i =
0
; i < files.length; i++) {
...
}
}
}
|
糟糕！前者違反了 Java 編碼中 10 個微妙的最佳實踐 的規則＃5和＃6。所以必定要記得判 null檢查！函數
3. 不要相信「-1」
我知道這很偏執，Javadoc中關於 String.indexOf() 的早期描述是這樣的…
「字符在字符序列中第一次出現的位置將做爲結果[被返回]，若是字符不存在則返回-1。」
因此，-1 就能夠理所固然被拿來用，對嗎？我說不對，看看這個：
|
1
2
3
4
5
|
// Bad
if
(string.indexOf(character) != -
1
) { ... }
// Good
if
(string.indexOf(character) >=
0
) { ... }
|
誰知道呢。也許在某個特定場合下他們將會須要另外一種 編碼值，若是不區分大小寫的話，otherString 就會被包含進去…此時或許能夠返回 -2呢？誰知道呢。
畢竟，咱們有很是多關於NULL——價值億萬美金的錯誤的討論。爲何不開始討論 -1呢，某種意義上來講 -1 是 null 在int類型下的另外一種形式。
4. 避免意外的賦值
是的。即便最優秀的程序員也可能犯這種錯誤（固然，不包括我。看#7）。
（假設這是JavaScript，咱們暫且偏執地認爲是這種語言）
|
1
2
3
4
5
6
7
8
|
// Ooops
if
(variable =
5
) { ... }
// Better (because causes an error)
if
(
5
= variable) { ... }
// Intent (remember. Paranoid JavaScript: ===)
if
(
5
=== variable) { ... }
|
再說一遍。若是你的表達式中有常量，將它放在等式左邊。這樣當你打算再添加一個 = 時，不容易出錯。
5. 檢查null和長度
無論何時你有一個集合、數組或者其餘的，確保它存在而且不爲空。
|
1
2
3
4
5
|
// Bad
if
(array.length >
0
) { ... }
// Good
if
(array !=
null
&& array.length >
0
) { ... }
|
你不知道這些數組來自哪兒，也許是早期的JDK API呢？
6. 全部的方法都用 final 聲明
你能夠告訴我任何你想要的開閉原則，不過那都是胡說八道。我不相信你（能夠正確繼承個人類），也不相信我本身（不會意外地繼承個人類）。所以除了接口（專門用於繼承）都應該是嚴格的 final。能夠查看咱們的 Java 編碼中 10 個微妙的最佳實踐 中的#9。
|
1
2
3
4
5
|
// Bad
public
void
boom() { ... }
// Good. Don't touch.
public
final
void
dontTouch() { ... }
|
是的，寫成final。若是這樣作對你來講沒有意義，你也能夠經過修改或重寫字節碼來改變類和方法，或者發送功能請求。我敢確定重寫類/方法並非一個好主意。
7. 全部的變量和參數都用 final 聲明
就像我說的。我不相信本身不會無心間重寫了某個值。這麼說來，個人確一點都不相信本身。由於：
這也是爲何全部的變量和參數都用final聲明的緣由。
|
1
2
3
4
5
6
7
8
9
10
11
|
// 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 中 直到那該死的編譯器中止工做，而後他們忽然連接到了錯誤的方法，認爲這一切都是你的錯（事情老是這樣）。
思考一下這個：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
// 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) {
...
}
|
由於，你知道的…你的用戶們，他們就像這樣
|
1
2
3
4
|
// This library sucks
@SuppressWarnings
(
"all"
)
Object t = (Object) (List) Arrays.asList(
"abc"
);
bad(t);
|
相信我，我看過的多了，還有這樣的
因此說偏執是有好處的。
9. 老是在switch語句里加上default
Switch…做爲最滑稽的表達式之一，我不知道是該心存敬畏仍是默默哭泣。無論怎樣，咱們既然沒法擺脫 switch ，在必要的時候咱們最好可以正確使用它，例如：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
// 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 就能發揮做用，使其正常運行！別和我提 enum 類型，由於這對 enums 也同樣適用。
10. 用大括號隔開 switch 的每個 case 塊
事實上，switch是最坑爹的語句，任何喝醉了或是賭輸了的人均可以在某種語言中使用它。看看下面這個例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
// 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，它的神祕已經超越了它的功能。
這意味着變量final int j 能夠被任何case訪問，不論咱們是否有break。看起來並非很直觀。咱們能夠經過添加簡單的花括號爲每個case建立一個新的嵌套的做用域，固然不要忘了在每一個 case 的語句塊最後加 break。
結論
編程時的強迫症有時候看起來會很奇怪，會使得代碼每每比必需的還要冗長。你可能會想，「啊，這種狀況永遠不會發生！」，可是正如我所說的，在經歷了20年左右的編程生涯後，你不會想要再去修正那些只是由於編程語言的古老和固有缺陷而致使的愚蠢而沒必要要的bug了。由於你知道…..
如今，輪到你了！
你在編程時有哪些強迫症呢？
原文連接： javacodegeeks 翻譯： ImportNew.com - LynnShaw譯文連接： http://www.importnew.com/16805.html
[ 轉載請保留原文出處、譯者和譯文連接。]