第一章
童子军军规
让营地比你来时更干净
第二章.有意义的命名
1. 变量命名 (名副其实)
a) Data ->? Property ->? Age? Address?
2. 避免误导
a) AccountList 注意容器是否是list
b) XYZControllerForEfficientHandlingOfStrings 和 XYZControllerForEfficientStorageOfStrings 过于相近
3. 做有意义的区分
a) A1,a2,a3 source destination
b) Produce prductInfo
4. 使用都得出来的名称
a) Genymdhms(生成日期你,年月日时分秒)
GenerationTimestamp
5. 使用可搜索的名称
a) Const int WORK_DAYS_PER_WEEK =5
For( int j =0 ; j<= WORK_DAYS_PER_WEEK;j++){ …..}
6. 避免使用编码
a) 匈牙利语标记法
b) 成员前缀
i. m_dsc 成员变量
c) 接口和实现
i. IshapeFactory ShapeFactory
7. 避免思维映射
a) 循环技术中I,j,k避免,需要读者映射到真实概念
8. 类名 ->名词 名词短语
a) WikiPage,Accountd等,避免用Manager,DataProcessor…
9. 方法名 ->动词 动词短语
a) String name = employee.getName()
b) If( paycheck.isPosted()){…}
c) Complex fulcrumpoint = Complex.FromRealNumber( 23.0 )好于 Complex fulcrumpoint = new Complex ( 23 .0)
10. 别扮可爱
a) HolyHandGrenade deleteItems
11. 每个概念对应一个词
a) 为每个抽象概念选择选择一个词,并且一以贯之
12. 别用双关语
a) Add 两个相加 还是 把元素 添加到 colletion
13. 使用解决方案领域名称
a) 只有程序员才会阅读你的代码 所以放心大胆的用CS的术语,算法名
14. 使用源自所涉问题领域的名称
a) 如果不能用程序员熟悉的术语给手头的工作命名,那么就用所设问题的领域的名称。
b) 分离解决方案领域和问题领域的概念。
15. 添加有意义的语境
16. 不要添加没用的语境
a) 对于Addresss类的实体来说,accountAddress和customerAddress都是不错的名称,但是用在类名就不好了。Address是个好类名,如果需要与MAC地址,端口地址,和Web地址相区别,考虑使
用postalAddress,MAC,URI
第三章.函数
1. 短小
每个函数只有几行,每个函数一目了然,每个函数依次把你带到下一个函数
2. 只做一件事
代码清单3-1创建缓冲区,获取页面,搜索继承下来的页面,渲染页面,添加神秘字符串,生成html…
代码3-3只做一件事,设置和拆解 到测试页面中
要判断函数是否只做了一件事,还有一个办法,就是看是否能再拆出一个函数,该函数不仅只是单纯的重新诠释其实现。
3. 每个函数一个抽象层级
自定向下读代码:向下规则
每个函数后面都跟着位于下一抽象等级的函数。在查看函数列表时,就能循抽象层向下阅读。
4.使用描述性的名称
如果每个例程都让你感到深合己意,那就是整洁代码
别害怕长名称,长具有描述性的名称,要比短而令人费解的好
5. 函数参数
越少越好,尽量别有。如果从测试的角度看,所有的可能值的组合简直让人生畏
一元参数的普遍形式:
转换(返回类型要体现出转换);事件(有输入参数,没有输出)
标识参数:
向函数传入布尔值简直是骇人听闻,这样做,方法签名立刻变得复杂起来,宣布其函数不止做一件事。
二元参数:
writeField(name) 比 writeField(outputstream,name)
new point(0,0)
assertEquals(expected,actual)
三元参数:
assertEquals(message,expected,actual)
assertEquals(1.0,amount,0.01)
参数对象:
当出现3个及三个以上的参数,其中的一些参数应该封装为类
参数列表:
可变参数可以被同等对待,就和类型为List的单个参数没什么两样。
动词与关键字
Write(name) 告诉我们 name不管是什么,要被write
6.无副作用
检查密码,却对现有会话进行了初始化。
虽然改成checkPasswordAndInitializeSession,但是违反了 “只做一件事的原则“SRP
7. 分隔指令与询问
8. 使用异常替代返回错误代码
从指令函数返回错误码轻微违反了指令与询问分隔的规则,导致了更深层次的嵌套
使用异常替代返回错误码,错误处理代码就能从主路径代码中分离出来。
① .抽离try/catch代码块
抽出try和catch的代码块的主体部分,另外形成新函数
9. 别重复自己
重复可能是软件中一切邪恶的根源。 重复->修改错误不好 ->可读性不好
10.结构化编程
Dijkastra认为,每个函数、函数中的每个代码块都应该有一个入口,一个出口。
只要函数精简,偶尔出现retrun,break,continue没有坏处。
11.如何写出这样的函数
打磨。人无完人,分解函数,修改名称,消除重复。