代码整洁之道 读书笔记 - 第2章 有意义的命名

名副其实

1、选个好名字要花时间,但省下来的时间比花掉的多

2、一旦发现有更好的名称,就换掉旧的

3、如果名称需要注释来补充,那就不算是名副其实

避免误导

1、应当避免使用与本意相悖的词

    hp、aix和sco都不该用做变量名,因为它们都是UNIX平台或类UNIX平台的专有名称。

    别用accountList来指称一组账号,除非它真的是List类型。用accountGroup或bunchOfAccounts,甚至直接用accounts都会好一些。

2、提防使用不同之处较小的名称

    XYZControllerForEfficientHandlingOfStrings和XYZControllerForEfficientStorageOfStrings这两个词外形太相似了。

做有意义的区分

1、同一作用范围内两样不同的东西不能重名,可能会随手改掉其中一个的名称,有时干脆以错误的拼写充数

    例如,就因为class已有他用,就给一个变量命名为klass,这真是可怕的做法。

2、废话是另一种没意义的区分

    假设你有一个Product类。如果还有一个ProductInfo或ProductData类,它们的名称虽然不同,意思却无区别。

    废话都是冗余。Variable一词永不应当出现在变量名中。Table一词永远不应当出现在表名中。NameString会比Name好吗?难道Name会是一个浮点数不成?

使用读得出来的名称

人类长于记忆和使用单词,不要使用自造词,比较

class DtaRcrd102 {
  private Date genymdhms;
  private Date modymdhms;
  private final String pszqint = "102";
  /* ... */
};

class Customer {
  private Date generationTimestamp;
  private Date modificationTimestamp;
  private final String recordId = "102";
  /* ... */
};

generationTimestamp比genymdhms更容易看懂一些了。

使用可搜索的名称

若变量和常量可能在代码中多处使用,则应赋其以便于搜索的名称,比较

for (int j=0; j<34; j++) {
  s += (t[j]*4)/5;
}

int realDaysPerIdealDay = 4;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
for (int j=0; j<NUMBER_OF_TASKS; j++) {
  int realTaskDays = taskEstimate[j] * readDaysPerIdealDay;
  int realTaskWeeks = (realdays / WORK_DAYS_PER_WEEK);
  sum += realTaskWeeks;
}

采用能表达意图的名称,貌似拉长了函数代码,但要想想看,WORK_DAYS_PER_WEEK要比数字5好找得多。

避免使用编码

1、匈牙利标记法(Hungarian Notation,HN)

在Windows的C语言API的时代,编译器不做类型检查,程序员需要匈牙利语标记法来帮助自己记住类型。而现代编程语言对象是强类型的,所以HN就纯属多余了。

PhoneNumber phoneString;    //  类型变化时,名称并不变化

2、成员前缀

不必用m_前缀来标明成员变量,人们会很快学会无视前缀(或后缀),只看到名称中有意义的部分。

public class Part {
  private String m_dsc;  // 文字描述
  void setName(String name) {
    m_dsc = name;
  }
}
———————————————————————————————
public class Part {
  String description;
  void setDescription(String description) {
    this.description = description;
  }
}

3、接口和实现

如何命名接口和实现?IShapeFactory和ShapeFactory吗?

不用加前导字母I来修饰接口,也不用让用户知道我给他们的是接口。只用让他们知道那是个ShapeFactory。

如果接口和实现必须选一个编码,那就在实现上编码。如:ShapeFactoryImp,甚至是丑陋的CShapeFactory。

避免思维映射

不应当让读者在脑中把你的名称翻译为他们熟知的名称。

类名

1、类名和对象名应该是名词或名词短语,如Customer、WikiPage、Account他AddressParser。避免使用Manager、Processor、Data或Info这亲的类名。

2、类名不应该是动词

方法名

1、方法名应当是动词或动词短语,如postPayment、deletePage或save

2、属性访问器、修改器和断言应该根据其值命名,并加上get、set和is前缀

string name = employee.getName();
customer.setName("mike");
if (paycheck.isPosted()) ...

3、重载构造器时,使用描述了参数的静态工厂方法名

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

通常好于

Complex fulcrumPoint = new Complex(23.0);

可以考虑将相应的构造器设置为private,强制使用这种命名手段。

别扮可爱

扮可爱的做法在代码中经常体现为使用俗话或俚语

    别用HolyHandGrenade来表示DeleteItems    注:HolyHandGrenade意为“圣手手雷”

    别用whack()来表示kill()    注:whack,美俚,意为“劈砍”

    别用eatMyShorts()来表示abort()    注:eatMyShorts,美俚,意为“去死吧”

每个概念对应一个词

给每个抽象概念选一个词,并且一以贯之。例如,使用fetch、retrievet和get来给在多个类中的同种方法命名。怎么记得住哪个类中是哪个方法呢?

别用双关语

避免将同一单词用于不同目的。遵循“一词一义”规则。比如,在多个类中都有add方法,该方法通过增加或连接两个现存值来获得新值。假设再要写一个新类,该类中有一个方法,把单个参数放到群集中,该方法就不能叫做add。

使用解决方案领域名称

只有程序员才会读你的代码。所以,尽量用那些计算机科学术语、算法名、模式名、数学术语。

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

如果不能用程序员熟悉的术语来给手头的工作命名,就采用从所涉问题领域而来的名称。至少,负责维护代码的程序员能去请教领域专家。

添加有意义的语境

需要用有良好命名的类、函数或名称空间来放置名称,给读者提供语境。如果没这么做,给名称添加前缀就是最后一招了。

firstName、lastName、state可以添加前缀addrFirstName、addrLastName、addrState来提供语境。当然,更好的方案是创建名为Address的类。

不要添加没用的语境

若有一个名为“加油站豪华版”(Gas Station Deluxe)的应用,在给每个添加GSD前缀就不是什么好点子。这样做的坏处就是IDE的自动完成功能完全就起不了作用。

猜你喜欢

转载自www.cnblogs.com/TanSea/p/ClearCode-2.html