編碼風格和開發習慣

在指令式程式設計中，執行緒之間的通訊機制有兩種共享記憶體和訊息傳遞。

  指令式程式設計也稱為指令式程式設計，可以理解為運算語句，迴圈語句，條件分支語句和無條件分支語句（goto語句）形式的程式設計。
  物件導向程式設計在指令式程式設計基礎上新增了物件擴充套件。
  函數語言程式設計最重要的基礎是λ演算（lambda calculus）。相比指令式程式設計，其更加強調程式執行的結果而非執行的過程，倡導利用若干簡單的執行單元讓計算結果不斷漸進，逐層推導複雜的運算，而不是設計一個複雜的執行過程，而且λ演算的函式可以接受函式當作輸入（引數）和輸出（傳出值）
  響應式程式設計是一種面向資料流和變化傳播的非同步程式設計範例，資料流可以是I/O，事件等。一種是函式響應式程式設計FPR，一種是具有函式風格的響應式實現——響應式函式程式設計RFP（reactive-functional programming）。

作為Java開發人員，我們會遵循一系列的編碼風格和開發習慣。習慣使然是一方面，另一方面，我們也從不停下腳步質疑這些習慣。

> 零註釋（公共 API 除外） 

讓我們再次探討這個問題：無註釋。註釋很快就會與程式碼脫節。假如你在一段程式碼的上面寫了行註釋，誰也不能保證下一個修改程式碼的人會更新註釋。根據筆者的開發經驗，沒人會更新註釋。原來的程式碼段可能被刪除，業務需求也可能改變。因此，你的註釋往往弊大於利。 

對此，有個簡單的解決方案，就是寫自記錄程式碼（self documenting code）。對變數、物件或者函式等進行命名時，選擇能清晰表達其用途的名字。假如不夠清晰，你需要對它們進行重構，將之拆分為更簡潔的形式。只要能直觀地表達其用途，過長的名字也無需擔憂。別忘了編輯器有自動填寫功能，沒人需要敲出整個識別符號的名字。

然而，公共API是一個明顯的例外。假如你正在建立一個準備公開發版的庫，那還是使用簡潔的方法名比較好。不過， Javadoc對這種情況大有裨益，但也僅限此情況。

> 不要用 “Test” 為測試方法開頭 
確實沒有必要這麼做。你寫的方法會註釋為測試，方法所在的類也存在於測試包中。明眼人都知道那是測試。其實，測試方法名應該明確指出測試的內容與條件。例如， “reversesTheWordRandomToModnar()”或者“adds70ToBalanceOf100ToMakeBalanceOf170()”，這些名字都準確表達了測什麼功能以及預期的結果。

>不要使用@Override 
這個觀點爭議頗多，請聽筆者說完。假如你不使用 @override ，最壞的結果就是你重寫了一個函式，而呼叫時執行的卻是原版函式，而非重寫的版本。值得慶幸的是，在測試驅動開發模式下，測試整段程式碼時就會定位到這個 bug 。這讓 @Override 成了一段冗餘的程式碼。顯然，冗餘的程式碼不僅沒有好處，還會讓人分心。因此，停止使用 @Override ，而依賴 TDD（測試驅動開發）。 

>不要使用 getX()/setY() 這樣的函式名 
這確實讓人不由得感到惱火。 getXXX 和 setXXX 這種命名方式是 Javabeans 時代的前朝遺物。而 JavaBeans 時代早已過去，這種命名方式也不再適用了。後者讓程式碼變得令人反感卻沒有帶來什麼好處。去掉 get／set 這類關鍵字有利於欄位名稱的簡潔。例如， car.engine() 函式將生成一個引擎物件，而 car.engine(new v8()) 將引擎設定為新的型號。如果需要讀取多層級內的物件（例如：car.lights().frontLeft() 對比 car.getLights().getFrontLeft()），前者依舊錶達清晰而且程式碼更加簡潔。這個程式設計習慣筆者一開始也很反對，後來逐漸改變了看法，現在非常熱衷這一風格。

>可執行的程式碼>高效能的程式碼 
這段內容和程式碼風格關係不大，而是更加泛泛而談。每次看到人們為了一個問題，精雕細刻地設計解決方案，花費大量的時間，筆者都會感到不悅。其實，在最基本的層面上解決問題然後測試效能。十有八九，這類方案都是高速，可擴充套件或符合其他時髦概念的。相反，筆者經常看到人們設計了一個複雜的快取解決方案，結果沒有提高效能卻把程式碼弄成一團亂麻。解決問題時，先實施你能採取的最基本方案，然後再進行優化。最起碼，這種方式能讓你有例項證明問題已經解決。 

>使用自己的異常型別 
筆者又一次錯誤地認為這一開發習慣是業內的共識。 Java 中的檢查性異常 （Checked exceptions） 很糟糕，幾乎所有其他程式語言（例如C＃）都意識到了這一點，所以它們甚至沒有這個型別。在筆者編寫的任何應用程式中，都會建立自己的異常型別，在這些應用程式中丟擲的任何異常都會用筆者建立的異常類接住，然後丟擲執行時異常。這讓程式碼更加整潔（筆者從未在程式中丟擲大量 XXXException ），也意味著筆者能通過 log 追朔異常來自程式碼的哪一部分或者這是完全出乎意料的異常型別。