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

 方法如果有太多縮進，可以通過extract method的方法消除。這里它還提到了一個原則就是方法的行數盡量控制在5行之內。這樣對單個方法來說確實是簡單了不少，但過多的方法調用是否也影響了代碼的可讀性？

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

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

  4和5我倒是贊同，也是我平時一直在強調的。

  第6條，每個類的長度不能超過50行，我想應該不包括注釋和import吧，不過50行確實是個挑戰，想想我們自己寫的類，哪個不是上百行的，有的甚至達到了千行。

  第7條：大多數的類應該只負責處理單一的狀態變量，有些時候也可以擁有兩個狀態變量。每當為類添加一個實例變量，就會立即降低類的內聚性。一般而言，編程時如果遵守這些規則，你會發現只有兩種類，一種類只維護一個實例變量的狀態；另一種類只負責協調兩個獨立的變量。不要讓這兩種職責同時出現在一個類中。比如：

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

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

  Class GivenNames {
      List<String> names;
   }

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

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

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