《代码整洁之道》读书笔记二

第二章讲的是 有意义的命令

 1.名副其实。 说起来很简单。选个好名字需要花时间，但省下的时间比花掉的多。注意命名，一旦有好的命名，就换掉旧的。

 int d;// 消失的时间，以日计。
 int elapsedTimeInDays;

2.避免误导。比如不是List类型，就不要用个accountList来命名，这样形成误导。

3.做有意的区分。 

如果参数名称改为source和destination ，这个函数就会像样很多。废话都是冗余的，Variable一词 永远不应当出现在变量名中。Table一词永远不应当出现在表名中。NameString 会比 Name好吗，难道Name 会是一个浮点数不成？如有一个Customer的类，有又一个CustomerObject的类。是不是就凌乱了。

4.使用便于搜索的的名称

单个字母或者数字常量是很难在一大堆文章中找出来。比如字母e，它是英文中最常用的字母。长名胜于短名称，搜得到的名称胜于自编的名称。 窃以为单字母的名称仅用于短方法中的本地变量。名称长短应与其作用域大小相对应。

5.类名应该是名词或短语，像Customer，Account，避免使用Manager,Processor,Data或者Info这样的类名。类名不应当是动词。方法名应该是动词或动词短语，如postPayment ,deletePage或Save，属性访问、修改和断言应该根据其值来命名，并加上get，set，is这些前缀。

6.别扮可爱，耍宝，比如谁知道HolyHandGrenada 函数是干什么的，没错这个名字挺伶俐，但是不过DeleteItems或许是更好的名字。

7.每个概念对应一个词。并且一以贯之。 

  在一堆代码中有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.不要重复自己。