在沉浸于編碼一段時(shí)間以后，你就會(huì)漸漸明白任何事情有可能出錯(cuò)，這就是為什么我們要采用“防御性編程”，即一些偏執(zhí)習(xí)慣的原因。下面是動(dòng)力節(jié)點(diǎn)的Java老師為大家整理的大牛眼中的10個(gè)非常有用但偏執(zhí)的Java編程技術(shù)。一起來(lái)看一看吧：
1、將String字符串放在zui前面
為了防止偶發(fā)性的NullPointerException異常，我們通常將String放置在equals()函數(shù)的左邊來(lái)實(shí)現(xiàn)字符串比較，如下代碼：
//Bad
if(variable.equals("literal")){...}
//Good
if("literal".equals(variable)){...}
這是隨便用腦子想想就可以做的事，從Bad版本的代碼改寫表達(dá)式到Good版本的代碼，這中間并不會(huì)丟失任何東西。歡迎不同的觀點(diǎn)…
2、不要相信早期的JDKAPI
在Java早期，編程是一件非常痛苦的事情。那些API仍然很不成熟，也許你已經(jīng)碰到過(guò)下面的代碼塊：
String[]files=file.list();
//Watchout
if(files!=null){
for(inti=0;i<files.length;i++){
...
}
}
看上去很偏執(zhí)？也許吧，但請(qǐng)看Javadoc：
如果這個(gè)虛擬路徑不表示一個(gè)文件夾目錄，則此方法返回null。否則將會(huì)返回一個(gè)字符串?dāng)?shù)組，每一個(gè)字符串表示目錄中的文件或文件夾。
對(duì)，沒(méi)錯(cuò)。我們可以添加一些校驗(yàn)：
if(file.isDirectory()){
String[]files=file.list();
//Watchout
if(files!=null){
for(inti=0;i<files.length;i++){
...
}
}
}
3、不要相信“-1”
我知道這是偏執(zhí)的，但Javadoc中對(duì)String.indexOf()方法明確指出：對(duì)象內(nèi)第一次出現(xiàn)指定字符的位置索引，如果為-1則表示該字符不在字符序列中。
所以使用-1是理所當(dāng)然的，對(duì)嗎？我說(shuō)不對(duì)，請(qǐng)看以下代碼：
//Bad
if(string.indexOf(character)!=-1){...}
//Good
if(string.indexOf(character)>=0){...}
誰(shuí)知道呢。也許到時(shí)候他們改變了編碼方式，對(duì)字符串并不區(qū)分大小寫，也許更好的方式是返回-2？誰(shuí)知道呢。
4、避免意外賦值
是的。這種事情也許經(jīng)常會(huì)發(fā)生。
//Ooops
if(variable=5){...}
//Better(becausecausesanerror)
if(5=variable){...}
//Intent(remember.ParanoidJavaScript:===)
if(5===variable){...}
所以你可以將比較常量放置在左側(cè)，這樣就不會(huì)發(fā)生意外賦值的錯(cuò)誤了。
5、檢查Null和Length
無(wú)論如何，只要你有一個(gè)集合、數(shù)組等，請(qǐng)確保它存在，并且不為空。
//Bad
if(array.length>0){...}
//Good
if(array!=null&&array.length>0){...}
你并不知道這些數(shù)組從哪里來(lái)，也許是來(lái)自早期版本的JDKAPI，誰(shuí)知道呢。
6、所有的方法都是final的
你也許會(huì)告訴我你的開(kāi)/閉原則，但這都是胡說(shuō)八道。我不相信你（正確繼承我這個(gè)父類的所有子類），我也不相信我自己（不小心繼承我這個(gè)父類的所有子類）。所以對(duì)于那些意義明確的方法要嚴(yán)格用final標(biāo)識(shí)。
//Bad
publicvoidboom(){...}
//Good.Don'ttouch.
publicfinalvoiddontTouch(){...}
7、所有變量和參數(shù)都是final
//Bad
voidinput(StringimportantMessage){
Stringanswer="...";
answer=importantMessage="LOLaccident";
}
//Good
finalvoidinput(finalStringimportantMessage){
finalStringanswer="...";
}
8、重載時(shí)不要相信泛型
是，它可以發(fā)生。你相信你寫的超級(jí)好看的API，它很直觀，隨之而來(lái)的，一些用戶誰(shuí)只是將原始類型轉(zhuǎn)換成Object類型，直到那該死的編譯器停止發(fā)牢騷，并且突然他們會(huì)鏈接錯(cuò)誤的方法，以為這是你的錯(cuò)誤。
看下面的代碼：
//Bad
<T>voidbad(Tvalue){
bad(Collections.singletonList(value));
}
<T>voidbad(List<T>values){
...
}
//Good
final<T>voidgood(finalTvalue){
if(valueinstanceofList)
good((List<?>)value);
else
good(Collections.singletonList(value));
}
final<T>voidgood(finalList<T>values){
...
}
因?yàn)?，你知?hellip;…你的用戶，他們就像
//Thislibrarysucks
@SuppressWarnings("all")
Objectt=(Object)(List)Arrays.asList("abc");
bad(t);
相信我。這一切我都看到過(guò)。包括下面的
這種偏執(zhí)還是不錯(cuò)的。
9、總是在Switch語(yǔ)句的Default中拋出異常
Switch語(yǔ)句……它們其中一個(gè)可笑的語(yǔ)句我不知道該對(duì)它敬畏還是哭泣，但無(wú)論如何，既然我們堅(jiān)持用switch，那我們不妨將它用得優(yōu)美，看下面的代碼：
//Bad
switch(value){
case1:foo();break;
case2:bar();break;
}
//Good
switch(value){
case1:foo();break;
case2:bar();break;
default:
thrownewThreadDeath("That'llteachthem");
}
當(dāng)value==3時(shí)，將會(huì)出現(xiàn)無(wú)法找到的提示，而不會(huì)讓人不知所謂。
10、Switch語(yǔ)句帶花括號(hào)
事實(shí)上，switch是最邪惡的語(yǔ)句，像是一些喝醉了或者賭輸了的人在寫代碼一樣，看下面的例子：
//Bad,doesn'tcompile
switch(value){
case1:intj=1;break;
case2:intj=2;break;
}
//Good
switch(value){
case1:{
finalintj=1;
break;
}
case2:{
finalintj=2;
break;
}
//Remember:
default:
thrownewThreadDeath("That'llteachthem");
}
在switch語(yǔ)句中，每一個(gè)case語(yǔ)句的范圍只有一行語(yǔ)句，事實(shí)上，這些case語(yǔ)句甚至不是真正的語(yǔ)句，他們就像goto語(yǔ)句中的跳轉(zhuǎn)標(biāo)記一樣。
結(jié)論
偏執(zhí)編程看起來(lái)似乎不可思議，有時(shí)，因?yàn)榇a經(jīng)常被證明是更詳細(xì)一點(diǎn)，但并不是需求需要。你可能會(huì)想，“哦，這是不會(huì)發(fā)生的”，但正如動(dòng)力節(jié)點(diǎn)Java老師所說(shuō)。經(jīng)過(guò)20年左右的時(shí)間編程，你不希望只修改這些愚蠢的bug。
京公網(wǎng)安備 11030102010736號(hào)