編程的智慧
編程是一件創造性的工作，是一門藝術。精通任何一門藝術，都需要很多的練習和領悟，所以這里提出的“智慧”，并不是號稱三天瘦二十斤的減肥藥，它并不能代替你自己的勤奮。然而我希望它能給迷惑中的人們指出一些正確的方向，讓他們少走一些彎路，基本做到一分耕耘一分收獲。
反復推敲代碼
既然“天才是百分之一的靈感，百分之九十九的汗水”，那我先來談談這汗水的部分吧。有人問我，提高編程水平最有效的辦法是什么？我想了很久，終于發現最有效的辦法，其實是反反復復地修改和推敲代碼。
在IU的時候，由于Dan Friedman的嚴格教導，我們以寫出冗長復雜的代碼為恥。如果你代碼多寫了幾行，這老頑童就會大笑，說：“當年我解決這個問題，只寫了5行代碼，你再回去想想吧……” 當然，有時候他只是夸張一下，故意刺激你的，其實沒有人能只用5行代碼完成。然而這種提煉代碼，減少冗余的習慣，卻由此深入了我的骨髓。
有些人喜歡炫耀自己寫了多少多少萬行的代碼，仿佛代碼的數量是衡量編程水平的標準。然而，如果你總是匆匆寫出代碼，卻從來不回頭去推敲，修改和提煉，其實是不可能提高編程水平的。你會制造出越來越多平庸甚至糟糕的代碼。在這種意義上，很多人所謂的“工作經驗”，跟他代碼的質量，其實不一定成正比。如果有幾十年的工作經驗，卻從來不回頭去提煉和反思自己的代碼，那么他也許還不如一個只有一兩年經驗，卻喜歡反復推敲，仔細領悟的人。
有位文豪說得好：“看一個作家的水平，不是看他發表了多少文字，而要看他的廢紙簍里扔掉了多少。” 我覺得同樣的理論適用于編程。好的程序員，他們刪掉的代碼，比留下來的還要多很多。如果你看見一個人寫了很多代碼，卻沒有刪掉多少，那他的代碼一定有很多垃圾。
就像文學作品一樣，代碼是不可能一蹴而就的。靈感似乎總是零零星星，陸陸續續到來的。任何人都不可能一筆呵成，就算再厲害的程序員，也需要經過一段時間，才能發現最簡單優雅的寫法。有時候你反復提煉一段代碼，覺得到了頂峰，沒法再改進了，可是過了幾個月再回頭來看，又發現好多可以改進和簡化的地方。這跟寫文章一模一樣，回頭看幾個月或者幾年前寫的東西，你總能發現一些改進。
所以如果反復提煉代碼已經不再有進展，那么你可以暫時把它放下。過幾個星期或者幾個月再回頭來看，也許就有煥然一新的靈感。這樣反反復復很多次之后，你就積累起了靈感和智慧，從而能夠在遇到新問題的時候直接朝正確，或者接近正確的方向前進。
寫優雅的代碼
人們都討厭“面條代碼”（spaghetti code），因為它就像面條一樣繞來繞去，沒法理清頭緒。那么優雅的代碼一般是什么形狀的呢？經過多年的觀察，我發現優雅的代碼，在形狀上有一些明顯的特征。
如果我們忽略具體的內容，從大體結構上來看，優雅的代碼看起來就像是一些整整齊齊，套在一起的盒子。如果跟整理房間做一個類比，就很容易理解。如果你把所有物品都丟在一個很大的抽屜里，那么它們就會全都混在一起。你就很難整理，很難迅速的找到需要的東西。但是如果你在抽屜里再放幾個小盒子，把物品分門別類放進去，那么它們就不會到處亂跑，你就可以比較容易的找到和管理它們。
優雅的代碼的另一個特征是，它的邏輯大體上看起來，是枝丫分明的樹狀結構（tree）。這是因為程序所做的幾乎一切事情，都是信息的傳遞和分支。你可以把代碼看成是一個電路，電流經過導線，分流或者匯合。如果你是這樣思考的，你的代碼里就會比較少出現只有一個分支的if語句，它看起來就會像這個樣子：
if (...) { if (...) { ... } else { ... }
} else if (...) { ... } else { ... }注意到了嗎？在我的代碼里面，if語句幾乎總是有兩個分支。它們有可能嵌套，有多層的縮進，而且else分支里面有可能出現少量重復的代碼。然而這樣的結構，邏輯卻非常嚴密和清晰。在后面我會告訴你為什么if語句最好有兩個分支。
寫模塊化的代碼
有些人吵著鬧著要讓程序“模塊化”，結果他們的做法是把代碼分部到多個文件和目錄里面，然后把這些目錄或者文件叫做“module”。他們甚至把這些目錄分放在不同的VCS repo里面。結果這樣的作法并沒有帶來合作的流暢，而是帶來了許多的麻煩。這是因為他們其實并不理解什么叫做“模塊”，膚淺的把代碼切割開來，分放在不同的位置，其實非但不能達到模塊化的目的，而且制造了不必要的麻煩。
真正的模塊化，并不是文本意義上的，而是邏輯意義上的。一個模塊應該像一個電路芯片，它有定義良好的輸入和輸出。實際上一種很好的模塊化方法早已經存在，它的名字叫做“函數”。每一個函數都有明確的輸入（參數）和輸出（返回值），同一個文件里可以包含多個函數，所以你其實根本不需要把代碼分開在多個文件或者目錄里面，同樣可以完成代碼的模塊化。我可以把代碼全都寫在同一個文件里，卻仍然是非常模塊化的代碼。
想要達到很好的模塊化，你需要做到以下幾點：
-
避免寫太長的函數。如果發現函數太大了，就應該把它拆分成幾個更小的。通常我寫的函數長度都不超過50行，那正好是我的筆記本電腦屏幕所能容納的代碼的行數。這樣我可以一目了然的看見一個函數，而不需要滾屏。50行并不是一個很大的限制，因為函數里面比較復雜的部分，往往早就被我提取出去，做成了更小的函數，然后從原來的函數里面調用。所以我寫的函數大小一般遠遠不足50行。
有些人不喜歡使用小的函數，因為他們想避免函數調用的開銷，結果他們寫出幾百行之大的函數。這是一種歷史遺留的錯覺。現代的編譯器都能自動的把小的函數內聯（inline）到調用它的地方，所以根本不產生函數調用，也就不會產生任何多余的開銷。
同樣的一些人，也愛使用宏（macro）來代替小函數，這也是一種歷史遺留的錯覺。在早期的C語言編譯器里，只有macro是靜態“內聯”的，所以他們使用宏，其實是為了達到內聯的目的。然而能否內聯，其實并不是宏與函數的根本區別。宏與函數有著巨大的區別（這個我以后再講），應該盡量避免使用宏。為了內聯而使用宏，其實是濫用了宏，這會引起各種各樣的麻煩，比如使程序難以理解，難以調試，容易出錯等等。
</li> -
每個函數只做一件簡單的事情。有些人喜歡制造一些“通用”的函數，既可以做這個又可以做那個，然后他們傳遞一個參數來“選擇”這個函數所要做的事情。這種“復用”其實是有害的。如果一個函數可能做兩種不一樣的事情，最好就寫成兩個不同的函數，否則這個函數的邏輯就不會很清晰，容易出現錯誤。
</li> </ul>寫可讀的代碼
有些人以為寫很多注釋就可以讓代碼更加可讀，然而卻發現事與愿違。注釋不但沒能讓代碼變得可讀，反而由于大量的注釋充斥在代碼中間，讓程序變得障眼難讀。而且代碼的邏輯一旦修改，就會有很多的注釋變得過時，需要更新。修改注釋是相當大的負擔，所以大量的注釋，反而成為了妨礙改進代碼的絆腳石。
實際上，真正優雅可讀的代碼，是幾乎不需要注釋的。如果你發現需要寫很多注釋，那么你的代碼肯定是含混晦澀，邏輯不清晰的。其實，程序語言的邏輯表達能力，是遠遠高于自然語言的。使用大量的自然語言去解釋程序的細節，是本末倒置的。
有人受到了Donald Knuth提出的所謂“文學編程”（Literate Programming）的誤導，認為程序里面注釋應該是主要的部分，而代碼其次，其實并不是這樣的。很多人（包括Knuth自己）使用文學編程，其實并沒有寫出一流的，容易理解的代碼。Knuth認為人與人之間交流，必須使用自然語言，而其實如果使用得當，程序語言能夠更加清晰精確地在人類之間傳遞信息。
之所以說“如果使用得當”，是因為如果沒能合理利用程序語言提供的優勢，你會發現程序還是很難懂，以至于需要寫注釋。所以我現在告訴你一些要點，也許可以幫助你大大減少寫注釋的必要：
-
使用有意義的函數和變量名字。如果你的函數和變量的名字，能夠切實的描述它們的邏輯，那么你就不需要寫注釋來解釋它在干什么。比如：
// put elephant elephant1 into fridge fridge2 putElephantIntoFridge(elephant1, fridge2);由于我的函數名
</li>putElephantIntoFridge已經說明了它要干什么（把大象放進冰箱），所以上面那句注釋完全沒有必要。 -
把復雜的邏輯提取出去，做成“幫助函數”。有些人寫的函數很長，以至于看不清楚里面的語句在干什么，所以他們誤以為需要寫注釋。如果你仔細觀察這些代碼，就會發現不清晰的那片代碼，往往可以被提取出去，做成一個函數，然后在原來的地方調用。由于函數有一個名字，這樣你就可以使用有意義的函數名來代替注釋。舉一個例子：
... ... ... ... // put elephant elephant1 into fridge fridge2 openDoor(fridge2); if (driveElephantIntoFridge(elephan1, fridge2)) { feedElephant(new Treat(), elephant1); } else { putBananaIntoFridge(new Banana(), fridge2); waitForElephantEnter(elephant1, fridge2); } closeDoor(fridge2); ... ... ... ...如果你把這片代碼提出去定義成一個函數：
function putElephantIntoFridge(elephant, fridge) { openDoor(fridge2); if (driveElephantIntoFridge(elephan1, fridge2)) { feedElephant(new Treat(), elephant1); } else { putBananaIntoFridge(new Banana(), fridge2); waitForElephantEnter(elephant1, fridge2); } closeDoor(fridge2); }然后原來的代碼就可以改成：
... ... ... ... putElephantIntoFridge(elephant1, fridge2); ... ... ... ...注釋就沒必要了。
</li> </ol>程序語言相比自然語言，是非常強大而嚴謹的，它其實已經具有自然語言的主要元素：主語，謂語，賓語，名詞，動詞，如果，因為，所以，否則，是，不是，…… 所以如果你充分利用了程序語言的表達能力，你完全可以用程序本身來表達它到底在干什么，而不需要自然語言的輔助。
有少數的時候，你也許會為了繞過其他一些代碼的設計問題，采用一種違反直覺的作法。這時候你就可以使用很短的一條注釋，說明為什么要寫成那奇怪的樣子。這樣的情況應該很少出現，否則這意味著整個代碼的設計都有問題。
寫簡單的代碼
現在我提出一些我自己正在使用的代碼規范，稍微解釋一下為什么它們能讓代碼更加簡單，從而提高代碼的質量。
-
避免使用i++和++i。這種自增減操作表達式含義很蹊蹺，非常容易搞混淆。而且含有它們的表達式的結果，有可能取決于參數的求值順序。其實這兩個表達式完全可以分解成兩步做，把讀寫操作分開：一步更新i的值，另外一步使用i的值。比如，如果你想寫
foo(i++)，你完全可以把它拆成int t = i; i += 1; foo(t);。如果你想寫foo(++i)，可以拆成i += 1; foo(i);拆開之后的代碼，含義完全一致，卻清晰很多。到底更新是在取值之前還是之后，非常的明顯。有人也許以為i++或者++i的效率比拆開之后要高，這只是一種誤解。這些代碼經過最基礎的編譯器優化之后，生成的機器代碼是完全沒有區別的。i++和++i，只有在兩種情況下可以安全的使用。一種是用在for循環語句的update部分，比如
</li>for(int i = 0; i < 5; i++)，另一種情況是寫在單獨的一行，比如i++;。這兩種情況是完全沒有歧義的。但是一定要避免把i++和++i用在復雜的表達式里面，比如foo(i++)，foo(++i) + foo(i)，…… 沒有人應該知道，或者去追究這些是什么意思。 -
永遠不要省略花括號。很多語言允許你在某種情況下省略掉花括號，比如C，Java都允許你在if語句里面只有一句話的時候省略掉花括號：
if (...) action1();咋一看少打了兩個字，多好。可是這其實經常引起奇怪的問題。比如，你后來想要加一句話
action2()到這個if里面，于是你就把代碼改成：if (...) action1(); action2();為了美觀，你很小心的使用了
action1()的縮進。咋一看它們是在一起的，所以你下意識里以為它們只會在if的條件為真的時候執行，然而action2()卻其實在if外面，它會被無條件的執行。我把這種現象叫做“光學幻覺”（optical illusion），理論上每個程序員都應該發現這個錯誤，然而實際上卻容易被忽視。那么你問，誰會這么傻，我在加入
action2()的時候加上花括號不就行了？可是從設計的角度來看，這樣其實并不是合理的作法。首先，也許你以后又想把action2()去掉，這樣你為了樣式一致，又得把花括號拿掉，煩不煩啊？其次，這使得代碼樣式不一致，有的if有花括號，有的又沒有。況且，你為什么需要記住這個規則？如果你不問三七二十一，只要是if-else語句，把花括號全都打上，就可以想都不用想了，就當C和Java沒提供給你這個特殊寫法。這樣就可以保持完全的一致性，減少不必要的思考。有人可能會說，全都打上花括號，只有一句話也打上，多礙眼啊？然而經過實行這種編碼規范幾年之后，我并沒有發現這種寫法更加礙眼，反而由于花括號的存在，使得代碼界限明確，讓我的眼睛負擔更小了。
</li> -
合理使用括號，不要盲目依賴操作符優先級。利用操作符的優先級來減少括號，對于
1+2*3這樣常見的算數表達式，是沒問題的。然而有些人如此的仇恨括號，以至于他們會寫出2 << 7 - 2 * 3這樣的表達式，而完全不用括號。這里的問題，在于移位操作
<<的優先級，是很多人不熟悉，而且是違反常理的。由于x << 1相當于把x乘以2，很多人誤以為這個表達式相當于(2 << 7) - (2 * 3)，所以等于250。然而實際上<<的優先級比加法+還要低，所以這表達式其實相當于2 << (7 - 2 * 3)，所以等于4！解決這個問題的辦法，不是要每個人去把操作符優先級表給硬背下來，而是合理的加入括號。比如上面的例子，最好直接加上括號寫成
</li>2 << (7 - 2 * 3)。雖然沒有括號也表示同樣的意思，但是加上括號就更加清晰，讀者不再需要死記<<的優先級就能理解代碼。 -
避免循環語句里面出現多個continue或者break。循環語句（for，while）里面出現return是沒有問題的，但是 continue和break會讓循環的邏輯和終止條件變得復雜，難以確保正確。如果只有一個continue或者break，也許還好，但是如果你的循環語句里面出現了多個continue或者break，你就該考慮改寫整個循環了。
出現多個continue或者break的原因，往往是對循環要執行的邏輯沒有想得很清楚。因為如果你考慮周全了，你應該幾乎不需要 continue或者break語句。改寫循環的辦法有多種，你也許可以把復雜的部分提取出來，做成函數調用，或者可以在分析清楚之后，把它變成另一種循環結構。
</li> </ul>寫直觀的代碼
我寫代碼有一條重要的原則：如果有更加直接，更加清晰的寫法，就選擇它，即使它看起來更長，更笨，也一樣選擇它。比如，Unix命令行有一種“巧妙”的寫法是這樣：
command1 && command2 && command3由于Shell語言的邏輯操作
a && b具有“短路”的特性，如果a等于false，那么b就沒必要執行了。這就是為什么當command1成功，才會執行command2，當command2成功，才會執行command3。同樣，command1 || command2 || command3操作符
||也有類似的特性。上面這個命令行，如果command1成功，那么command2和command3都不會被執行。如果command1失敗，command2成功，那么command3就不會被執行。這比起用if語句來判斷失敗，似乎更加巧妙和簡潔，所以有人就借鑒了這種方式，在程序的代碼里也使用這種方式。比如他們可能會寫這樣的代碼：
if (action1() || action2() && action3()) { ... }你看得出來這代碼是想干什么嗎？action2和action3什么條件下執行，什么條件下不執行？也許稍微想一下，你知道它在干什么：“如果 action1失敗了，執行action2，如果action2成功了，執行action3”。然而那種語義，并不是直接的“映射”在這代碼上面的。比如 “失敗”這個詞，對應了代碼里的哪一個字呢？你找不出來，因為它包含在了
||的語義里面，你需要知道||的短路特性，以及邏輯或的語義才能知道這里面在說“如果action1失敗……”。每一次看到這行代碼，你都需要思考一下，這樣積累起來的負荷，就會讓人很累。其實，這種寫法是濫用了邏輯操作
&&和||的短路特性。這兩個操作符可能不執行右邊的表達式，原因是為了機器的執行效率，而不是為了給人提供這種“巧妙”的用法。這兩個操作符的本意，只是作為邏輯操作，它們并不是拿來給你代替 if語句的。也就是說，它們只是碰巧可以達到某些if語句的效果，但你不應該因此就用它來代替if語句。如果你這樣做了，就會讓代碼晦澀難懂。上面的代碼寫成笨一點的辦法，就會清晰很多：
if (!action1()) { if (action2()) { action3(); } }這里我很明顯的看出這代碼在說什么，想都不用想：如果action1()失敗了，那么執行action2()，如果action2()成功了，執行action3()。你發現這里面的一一對應關系嗎？
if=如果，!=失敗，…… 你不需要利用邏輯學知識，就知道它在說什么。寫無懈可擊的代碼
在之前一節里，我提到了自己寫的代碼里面很少出現只有一個分支的if語句。我寫出的if語句，大部分都有兩個分支，所以我的代碼很多看起來是這個樣子：
if (...) { if (...) { ... return false; } else { return true; } } else if (...) { ... return false; } else { return true; }使用這種方式，其實是為了無懈可擊的處理所有可能出現的情況，避免漏掉corner case。每個if語句都有兩個分支的理由是：如果if的條件成立，你做某件事情；但是如果if的條件不成立，你應該知道要做什么另外的事情。不管你的 if有沒有else，你終究是逃不掉，必須得思考這個問題的。
很多人寫if語句喜歡省略else的分支，因為他們覺得有些else分支的代碼重復了。比如我的代碼里，兩個else分支都是
return true。為了避免重復，他們省略掉那兩個else分支，只在最后使用一個return true。這樣，缺了else分支的if語句，控制流自動“掉下去”，到達最后的return true。他們的代碼看起來像這個樣子：if (...) { if (...) { ... return false; } } else if (...) { ... return false; } return true;這種寫法看似更加簡潔，避免了重復，然而卻很容易出現疏忽和漏洞。嵌套的if語句省略了一些else，依靠語句的“控制流”來處理else的情況，是很難正確的分析和推理的。如果你的if條件里使用了
&&和||之類的邏輯運算，就更難看出是否涵蓋了所有的情況。由于疏忽而漏掉的分支，全都會自動“掉下去”，最后返回意想不到的結果。即使你看一遍之后確信是正確的，每次讀這段代碼，你都不能確信它照顧了所有的情況，又得重新推理一遍。這簡潔的寫法，帶來的是反復的，沉重的頭腦開銷。這就是所謂“面條代碼”，因為程序的邏輯分支，不是像一棵枝葉分明的樹，而是像面條一樣繞來繞去。
正確處理錯誤
使用有兩個分支的if語句，只是我的代碼可以達到無懈可擊的其中一個原因。這樣寫if語句的思路，其實包含了使代碼可靠的一種通用思想：窮舉所有的情況，不漏掉任何一個。
程序的絕大部分功能，是進行信息處理。從一堆紛繁復雜，模棱兩可的信息中，排除掉絕大部分“干擾信息”，找到自己需要的那一個。正確地對所有的“可能性”進行推理，就是寫出無懈可擊代碼的核心思想。這一節我來講一講，如何把這種思想用在錯誤處理上。
錯誤處理是一個古老的問題，可是經過了幾十年，還是很多人沒搞明白。Unix的系統API手冊，一般都會告訴你可能出現的返回值和錯誤信息。比如，Linux的read系統調用手冊里面有如下內容：
RETURN VALUE On success, the number of bytes read is returned... On error, -1 is returned, and errno is set appropriately.ERRORS EAGAIN, EBADF, EFAULT, EINTR, EINVAL, ...
很多初學者，都會忘記檢查
read的返回值是否為-1，覺得每次調用read都得檢查返回值真繁瑣，不檢查貌似也相安無事。這種想法其實是很危險的。如果函數的返回值告訴你，要么返回一個正數，表示讀到的數據長度，要么返回-1，那么你就必須要對這個-1作出相應的，有意義的處理。千萬不要以為你可以忽視這個特殊的返回值，因為它是一種“可能性”。代碼漏掉任何一種可能出現的情況，都可能產生意想不到的災難性結果。對于Java來說，這相對方便一些。Java的函數如果出現問題，一般通過異常（exception）來表示。你可以把異常加上函數本來的返回值，看成是一個union類型。比如：
String foo() throws MyException { ... }這里MyException是一個錯誤返回。你可以認為這個函數返回一個union類型：
{String, MyException}。任何調用foo的代碼，必須對MyException作出合理的處理，才有可能確保程序的正確運行。由于Java的類型系統強制要求函數在類型里面聲明可能出現的異常，而且強制調用者處理可能出現的異常，所以基本上不可能出現由于疏忽而漏掉的情況。但有些Java程序員有一種惡習，使得這種安全機制幾乎完全失效。每當編譯器報錯，說“你沒有catch這個foo函數可能出現的異常”時，有些人想都不想，直接把代碼改成這樣：
try { foo(); } catch (Exception e) {}或者最多在里面放個log，或者干脆把自己的函數類型上加上
throws Exception，這樣編譯器就不再抱怨。這些做法貌似很省事，然而都是錯誤的，你終究會為此付出代價。如果你把異常catch了，忽略掉，那么你就不知道foo其實失敗了。這就像開車時看到路口寫著“前方施工，道路關閉”，還繼續往前開。這當然遲早會出問題，因為你根本不知道自己在干什么。
catch異常的時候，你不應該使用Exception這么寬泛的類型。你應該正好catch可能發生的那種異常A。使用寬泛的異常類型有很大的問題，因為它會不經意的catch住另外的異常（比如B）。你的代碼邏輯是基于判斷A是否出現，可你卻catch所有的異常（Exception類），所以當其它的異常B出現的時候，你的代碼就會出現莫名其妙的問題，因為你以為A出現了，而其實它沒有。這種bug，有時候甚至使用debugger都難以發現。
如果你在自己函數的類型加上
throws Exception，那么你就不可避免的需要在調用它的地方處理這個異常，如果調用它的函數也寫著throws Exception，這毛病就傳得更遠。我的經驗是，盡量在異常出現的當時就作出處理。否則如果你把它返回給你的調用者，它也許根本不知道該怎么辦了。另外，你的try...catch，應該包含盡量少的代碼范圍。比如，如果
foo和bar都可能產生異常A，你的代碼應該盡量寫成：try { foo(); } catch (A e) {...} try { bar(); } catch (A e) {...}而不是
try { foo(); bar(); } catch (A e) {...}第一種寫法能明確的分辨是哪一個函數出了問題，而第二種寫法全都混在一起。明確的分辨是哪一個函數出了問題，有很多的好處。比如，如果你的catch代碼里面包含log，它可以提供給你更加精確的錯誤信息，這樣會大大地加速你的調試過程。
正確處理null指針
窮舉的思想是如此的有用，依據這個原理，我們可以推出一些基本原則，它們可以讓你無懈可擊的處理null指針。
-
首先你應該知道，許多語言（C，C++，Java，C#，……）的類型系統對于null的處理，其實是完全錯誤的。這些語言的類型系統允許null出現在任何對象（指針）類型可以出現的地方，然而null其實根本不是一個合法的對象。它不是一個String，不是一個Integer，也不是一個自定義的類。null的類型本來應該是NULL，也就是null自己。
</li> -
盡量不要產生null指針。盡量不要用null來初始化對象，函數盡量不要返回null。如果你的函數要返回“沒有”，“出錯了”之類的結果，盡量使用Java的異常機制。雖然寫法上有點別扭，然而Java的異常，和函數的返回值合并在一起，基本上可以當成union類型來用。比如，如果你有一個函數find，可以幫你找到一個String，也有可能什么也找不到，你可以這樣寫：
public String find() throws NotFoundException { if (...) { return "found"; } else { throw new NotFoundException(); } }Java的類型系統會強制你catch這個NotFoundException，所以你不可能像漏掉檢查null一樣，漏掉這種情況。Java的異常也是一個比較容易濫用的東西，不過我已經在上一節告訴你如何正確的使用異常。
</li> -
不要把null放進“容器數據結構”里面。所謂容器（collection），是指一些對象以某種方式集合在一起，所以null不應該被放進Array，List，Set等結構，不應該出現在Map的key或者value里面。把null放進容器里面，是一些莫名其妙錯誤的來源。因為對象在容器里的位置一般是動態決定的，所以一旦null從某個入口跑進去了，你就很難再搞明白它去了哪里，你就得被迫在所有從這個容器里取值的位置檢查null。你也很難知道到底是誰把它放進去的，代碼多了就導致調試極其困難。
解決方案是：如果你真要表示“沒有”，那你就干脆不要把它放進去（Array，List，Set沒有元素，Map根本沒那個entry），或者你可以指定一個特殊的，真正合法的對象，用來表示“沒有”。
需要指出的是，類對象并不屬于容器。所以null在必要的可以作為對象成員的值，表示它不存在。比如：
class A { String name = null; ... }之所以可以這樣，是因為null只可能在A對象的name成員里出現，你不用懷疑其它的成員因此成為null。所以你每次訪問name成員時，檢查它是否是null就可以了，不需要對其他成員也做同樣的檢查。
</li> -
函數調用者：盡早檢查和處理null返回值，減少它的傳播。如果你調用的函數有可能返回null，那么你應該在第一時間對null做出“有意義”的處理。比如，上述的函數
find，返回null表示“沒找到”，那么調用find的代碼就應該在它返回的第一時間，檢查返回值是否是null，并且對“沒找到”的情況作出有意義的處理。“有意義”是什么意思呢？我的意思是，使用這函數的人，應該明確的知道在拿到null的情況下該怎么做，承擔起責任來。他不應該只是“向上級匯報”，把責任踢給自己的調用者。如果你違反了這一點，就有可能采用一種不負責任，危險的寫法：
public String foo(String s) { if (s == null) { return null; } }當看到調用者給的參數是null，這函數自己也返回null。這樣null就從一個地方，游走到了另一個地方。如果你不假思索就寫出這樣的代碼，最后的結果就是代碼里面隨時隨地都可能出現null。到后來為了保護自己，你的每個函數都會寫成這樣：
public void foo(A a, B b, C c) { if (a == null) { ... } if (a == null) { ... } if (a == null) { ... } ... } -
函數作者：明確聲明不接受null參數，當參數是null時立即崩潰。不要試圖對null進行“容錯”，不要讓程序繼續往下執行。如果調用者使用了null作為參數，那么他應該對程序的崩潰負全責。上面的例子之所以成為問題，就在于人們對于null的“容忍態度”。
上面這種“保護式”的寫法，試圖“容錯”，試圖“優雅的處理null”，其結果是讓調用者更加肆無忌憚的傳遞null給你的函數。到后來，你的代碼里出現一堆堆nonsense的情況，null可以在任何地方出現，都不知道到底是哪里產生出來的。誰也不知道出現了null是什么意思，該做什么，所有人都把null踢給其他人。最后這null像瘟疫一樣蔓延開來，到處都是，成為一場噩夢。
正確的做法，其實是強硬的態度。你要告訴函數的使用者，我的參數全都不能是null，如果你給我null，程序崩潰了該你自己負責！至于調用者代碼里有null怎么辦，他自己該知道怎么處理（參考以上幾條），不應該由函數作者來操心。
</li> -
使用@NotNull和@Nullable標記。IntelliJ提供了@NotNull和@Nullable兩種標記，加在類型前面，這樣可以比較可靠地防止null指針的出現。IntelliJ本身會對含有這種標記的代碼進行靜態分析，指出運行時可能出現NullPointerException的地方。在運行時，會在null指針不該出現的地方產生IllegalArgumentException，即使那個null指針你從來沒有deference。這樣你可以在盡量早期發現并且防止null指針的出現。
</li> </ul>防止過度工程
人的腦子真是奇妙的東西。雖然大家都知道過度工程（over-engineering）不好，在實際的工程中卻經常不由自主的出現過度工程。所以我覺得必須分析一下過度工程出現的信號和兆頭，在初期的時候就避免它。
過度工程即將出現的一個重要信號，就是當你過度的思考“將來”，考慮一些還沒有發生的事情，還沒有出現的需求。比如，“如果我們將來有了上百萬行代碼，有了幾千號人，這樣的工具就支持不了了”，“將來我可能需要這個功能，所以我現在就把代碼寫來放在那里”，“將來很多人要擴充這片代碼，所以現在我們就讓它變得可重用”……
這就是為什么很多軟件項目如此復雜。實際上沒做多少事情，卻為了所謂的“將來”，加入了很多不必要的復雜性。眼前的問題還沒解決呢，就被“將來”給拖垮了。人們都不喜歡目光短淺的人，然而在現實的工程中，有時候你就是得看近一點，把手頭的問題先搞定了，再談以后擴展的問題。
另外一種過度工程的來源，是過度的關心“代碼重用”。很多人“可用”的代碼還沒寫出來呢，就在關心“重用”。為了讓代碼可以重用，最后被自己搞出來的各種框架捆住手腳，最后連可用的代碼就沒寫好。如果可用的代碼都寫不好，又何談重用呢？很多一開頭就考慮太多重用的工程，到后來被人完全拋棄，沒人用了，因為別人發現這些代碼太難懂了，自己從頭開始寫一個，反而省好多事。
過度地關心“測試”，也會引起過度工程。有些人為了測試，把本來很簡單的代碼改成“方便測試”的形式，結果引入很多復雜性，以至于本來一下就能寫對的代碼，最后復雜不堪，出現很多bug。
世界上有兩種“沒有bug”的代碼。一種是“沒有明顯的bug的代碼”，另一種是“明顯沒有bug的代碼”。第一種情況，由于代碼復雜不堪，加上很多測試，各種coverage，貌似測試都通過了，所以就認為代碼是正確的。第二種情況，由于代碼簡單直接，就算沒寫很多測試，你一眼看去就知道它不可能有bug。你喜歡哪一種“沒有bug”的代碼呢？
根據這些，我總結出來的防止過度工程的原則如下：
- 先把眼前的問題解決掉，解決好，再考慮將來的擴展問題。
- 先寫出可用的代碼，反復推敲，再考慮是否需要重用的問題。
- 先寫出可用，簡單，明顯沒有bug的代碼，再考慮測試的問題。 </ol> </div> 來自：http://www.jianshu.com/p/7645a5ea7f46
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
-
-
-