9.范围大小与变量名的长度
变量名的长度应和它的范围大小相匹配。如果变量的范围很短，那么变量名的长度也应该很短。反之，变量名则应该长一点，更有描述性。
10.范围大小与方法/类名的长度
对于方法和类名的长度则应该与其范围成反比。对于公共方法，短一点的名字会比较好，这是因为它们会被调用多次。私有方法只在类的范围内被调用，长一点的名字反而可以作为文档使用。此条规则的例外是派生类的名字。类越派生，基类前所加的形容词就越多，名字也就越长。
11.一个概念一个词
为某个抽象概念选定一个词，然后就不要变了。例如作为不同类中的等效方法，get()、fetch()和retrieve()会让人混淆起来。保持一致的词汇是程序员驾驭代码的重要工具。
12.不要将同一个词用于两个不同的概念
如果你遵循第11点——一个概念一个词的原则，那么就可以避免许多有着相同方法名的类。只要参数列表和各种方法的返回值在语义上是等价的就没问题。只有当你将同一个词用于两个不同的概念时才会出现问题。
例如，我们可以在多个类中使用add()方法，通过添加或连接两个现有的值来创建一个新的值。如果我们之后又需要在类中引入一个add方法用于添加参数到集合中，这就会因为语义不同而导致问题。这种新方法最好是改叫为insert()。
13.使用解决方案领域的名字
我们编写的代码今后可能会有其他程序员来阅读，所以我们使用一些技术术语进行代码命名会带来很大的好处。比如适当地使用算法名字、设计模式名字以及数学术语，这些命名方式很可能会让其他程序员更容易理解程序，引起共鸣。
14.使用问题领域的名字
如果实在找不到易于理解的技术术语来命名，那么也可以从问题领域来寻找合适的代码命名。当未来阅读你代码的程序员不确定代码意义的时候，这将为他们提供一些问题的线索。
15.添加有意义的语境
大多数名字其本身是没有意义的，并且需要放到语境（类/函数/命名空间）中，才能让阅读代码的人理解它们指代的是什么。在某些情况下，可能需要前缀名称以补充语境。例如，假设我们有一些用来表示地址的变量：firstName、lastName、street、houseNumber、city、state和zip。如果只看state这个变量，我们是很难推断出它指的是什么意思，一个比较好的解决办法就是将这些变量封装到Address类中。
16.不要添加没来由的语境
只要意思明确，短一点的名字通常比长的好，所以不要多此一举地添加语境。名字前不应该被加缀一些可以从类/包/命名空间中推断的不必要的信息。