最近看了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