Clean Code 读后感（二）

今天来到Clean Code 的第二章。

 

 

2.1 介绍：

到处都需要命名

 

2.2 名副其实：

取个好名字需要时间，但能让维护更省心；好的名称能明确体现上下文

 

2.3 避免误导：

不要使用与本意相悖的名称，要保持名称之间的区分度（注意不要单独使用l和O）

联想到Captcha 中最好不要出现的字符更多，比如

Z-2, O-0,  l-1,  I-l, S-5

 

 

2.4 做有意义的区分：

不要出现数字后缀，也不要废话

有个疑问，为什么不能用klass或者clazz呢？比如我就是想取单个对象的Class。

 

2.5 使用能读出来的名称：

不要用首字母缩写

 

2.6 使用可搜索的名称：

名称需要快速定位，避免使用单字母名称，其最多只能作为短方法的本地变量

 

2.7 避免使用编码：比如类型、作用域等

联想到以前写C++代码的习惯，又想到了当前Android的一些代码

 

2.7.1 匈牙利标记语法：

IDE持续改进，不再需要HN

 

2.7.2 成员前缀：

前缀是旧代码的标志物

 

2.7.3 接口前缀：

不加修饰的接口更好

 

2.8 避免思维映射：

明确、专业才是王道，避免思维映射

 

2.9 类名：

应该是名词或名词短语，不能是动词

 

2.10 方法名：

应该是动词或者动词短语，带描述的静态工厂方法优于Constructor

联想到 DSL，可以灵活一些，比如

 

 

item.computePrice() --> item.price()

 

 

2.11 别扮可爱：

应使用大众化的词语

 

2.12 每个概念对应一个词：

一以贯之的命名法，不要到处混用同义词

 

2.13 别用双关语：

做到“一词一义”

 

2.14 使用解决方案领域名称：

技术性名称最靠谱

 

2.15 使用源自所涉问题领域的名称：

当无法使用技术性名称时，可采用源自问题领域的名称

 

2.16 添加有意义的语境

做好抽象，类是天然的语境

 

2.17 不要添加没用的语境：

清楚简短的名称够用即可

 

2.18 最后的话：

命名需要良好的描述技巧和共有文化背景

 

最后有个问题是单元测试的函数命名问题。

比如：

 

shouldBeNotEqualsGivenTwoDifferentLengths();
shouldBeAnotherSmallLengthWhenBiggerLengthMinusASmallOne();

 

名称很长？不好断句？如果改成下划线分割呢？

 

should_be_not_equals_given_two_different_lengths();
should_be_another_small_length_when_bigger_length_minus_a_small_one();