第二章 有意义的命令
单个字母或者数字常量是很难在一大堆文章中找出来。比如字母e，它是英文中最常用的字母。长名胜于短名称，搜得到的名称胜于自编的名称。 窃以为单字母的名称仅用于短方法中的本地变量。名称长短应与其作用域大小相对应。
类名应该是名词或短语，像Customer，Account，避免使用Manager,Processor,Data或者Info这样的类名。类名不应当是动词。方法名应该是动词或动词短语，如postPayment ,deletePage或Save，属性访问、修改和断言应该根据其值来命名，并加上get，set，is这些前缀。
别扮可爱，耍宝，比如谁知道HolyHandGrenada 函数是干什么的，没错这个名字挺伶俐，但是不过DeleteItems或许是更好的名字。
每个概念对应一个词。并且一以贯之。
在一堆代码中有Controller，又有manager，driver。就会令人困惑。比如DeviceManager和Protal-Controller之间又什么本质区别？
第三章讲的是函数，说了这么一句话："Function should do one thing. They should do it well. They should do it only. "（函数只应该做一件事情，把一件事情做好，而且只由它来做这一件事情），听起来很简单的一句话但是要践行这条原则却并不容易，所以我们的代码中才会有很多的坏味道（请参考《重构：改善既有代码的设计》一书的第三章）。事实上，上升一个层次，我们在设计类的时候也应该如此，这是面向对象设计原则中说的单一职责原则（SRP），当我们的代码中出现了冗长的方法或者巨大的类的时候，我们就应该依据职责来对其进行拆分，这样程序的结构才会趋于合理，最终达到"高内聚"的目标。当然，这一章里面还提到很多理念，包括：Command Query Separation（一个方法要么执行某种命令，要么返回查询数据）、DRY（不要重复自己）、Prefer Exceptions to Returning Error Codes（异常优于返回错误码）等。
总结：
1.函数的第一规则是要短小，第二条规则是还要更短小。
2.函数应该做一件事。做好这件事。只做这一件事。
3.尽量少的函数参数。有两个参数的函数要比一元函数的难懂。如果需要三个或者三个以上的参数应该封装成类了。
4.不要重复自己。