最近看了thoughtworks的精選文集，第一章就是對(duì)象健身操，定了了九條編碼規(guī)范：
1. 方法只使用一級(jí)縮進(jìn)。
2. 拒絕使用else關(guān)鍵字。
3. 封裝所有的原聲類型和字符串。
4. 一行代碼只有一個(gè)‘.'運(yùn)算符。
5. 不用使用縮寫。
6. 保持實(shí)體對(duì)象簡(jiǎn)單清晰。
7. 任何類中的實(shí)例變量都不要超過2個(gè)。
8. 使用一流的集合。
9. 不使用任何Getter/Setter/Property。

 方法如果有太多縮進(jìn)，可以通過extract method的方法消除。這里它還提到了一個(gè)原則就是方法的行數(shù)盡量控制在5行之內(nèi)。這樣對(duì)單個(gè)方法來說確實(shí)是簡(jiǎn)單了不少，但過多的方法調(diào)用是否也影響了代碼的可讀性？

 丑陋的if-else, 相信不少人都看到過類似的討論，但究竟有多少人在用strategy pattern, Null Object pattern？ 實(shí)用和完美，你選擇哪個(gè)？

  第3條的意思是像integer，String這些類型都是沒有意義的，它們僅代表了一個(gè)值。如果你有一個(gè)方法setHour(int hour),應(yīng)該寫成這樣setHour(Hour hour),定義一個(gè)Hour類來代表小時(shí)，代碼的可讀性會(huì)大大提高，也保證了不會(huì)傳遞一個(gè)諸如year的錯(cuò)誤值給它。這條倒是蠻有挑戰(zhàn)性的。值得嘗試下。

  4和5我倒是贊同，也是我平時(shí)一直在強(qiáng)調(diào)的。

  第6條，每個(gè)類的長(zhǎng)度不能超過50行，我想應(yīng)該不包括注釋和import吧，不過50行確實(shí)是個(gè)挑戰(zhàn)，想想我們自己寫的類，哪個(gè)不是上百行的，有的甚至達(dá)到了千行。

  第7條：大多數(shù)的類應(yīng)該只負(fù)責(zé)處理單一的狀態(tài)變量，有些時(shí)候也可以擁有兩個(gè)狀態(tài)變量。每當(dāng)為類添加一個(gè)實(shí)例變量，就會(huì)立即降低類的內(nèi)聚性。一般而言，編程時(shí)如果遵守這些規(guī)則，你會(huì)發(fā)現(xiàn)只有兩種類，一種類只維護(hù)一個(gè)實(shí)例變量的狀態(tài)；另一種類只負(fù)責(zé)協(xié)調(diào)兩個(gè)獨(dú)立的變量。不要讓這兩種職責(zé)同時(shí)出現(xiàn)在一個(gè)類中。比如：

  Class Name {
      String first;
      String middle;
      String last;
  }

  可拆成這樣：
  Class Name {
     Surname family;
     GivenNames given;
   }
 
  Class Surname{
      String family;
   }

  Class GivenNames {
      List<String> names;
   }

  第8條： 任何包含集合的類都不能再包含其他的成員變量。每個(gè)集合都被封裝在自己的類中，這一條其實(shí)跟第3條類似。集合其實(shí)是一種應(yīng)用廣泛的原聲類型，它具有很多行為，但對(duì)于代碼的讀者和維護(hù)者來說，與集合相關(guān)的代碼通常都缺少對(duì)語義意圖的解釋。

  第9條： 上一條規(guī)則的最后一句話幾乎可以直接通向這條規(guī)則。如果可以從對(duì)象之外隨便詢問實(shí)例變量的值，那么行為與數(shù)據(jù)就不可能被封裝到一處。在嚴(yán)格的封裝邊界背后，真正的動(dòng)機(jī)是迫使程序員在完成編碼之后，一定要為這段代碼的行為找到一個(gè)合適的位置，確保它在對(duì)象模型中的唯一性。

 
  參考資料： http://www.infoq.com/cn/minibooks/thoughtworks-anthology