第二章讲的是 有意义的命令
int d;// 消失的时间,以日计。 int elapsedTimeInDays;
2.避免误导。比如不是List类型,就不要用个accountList来命名,这样形成误导。
如果参数名称改为source和destination ,这个函数就会像样很多。废话都是冗余的,Variable一词 永远不应当出现在变量名中。Table一词永远不应当出现在表名中。NameString 会比 Name好吗,难道Name 会是一个浮点数不成?如有一个Customer的类,有又一个CustomerObject的类。是不是就凌乱了。
4.使用便于搜索的的名称
单个字母或者数字常量是很难在一大堆文章中找出来。比如字母e,它是英文中最常用的字母。长名胜于短名称,搜得到的名称胜于自编的名称。 窃以为单字母的名称仅用于短方法中的本地变量。名称长短应与其作用域大小相对应。
第三章讲的是函数,说了这么一句话:"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(异常优于返回错误码)等。
总结: