Clean Code - 命名

1、 标准

• 低代码模糊度，好的代码命名可以在没有注释的情况下告诉读者其意义。尽量让 "这段代码在干什么？" 这个问题的答案就体现在代码本身。

2、 变量名

• 名副其实：命名尽量要体现出其本意

• 避免误导：提防使用外形相似度较高的名称，也避免使用容器名字作为后缀。

  • e.g. 其实我之前就曾经做过这样的事情，当时写了一个 Formula 模块来作为英雄属性计算类，代码大概就如下面所示，结果就是每次我去调用 Formula 在 IDE 中输入 Formula.Get 的时候，就会出现一大堆代码补全提示，但是都长得太相似了，以至于整个代码补全提示都变得很鸡肋。实际上所有函数的 GetHero 前缀去掉，让函数之间的相似度降低会好很多。

  •   class Formula : Singleton<Formula>
      {
           public int GetHeroAttack(Hero hero){ ... }
           public int GetHeroDefense(Hero hero){ ... }
           public int GetHeroCritical(Hero hero){ ... }
           public int GetHeroCriticalDamage(Hero hero){ ... }
           //...
      }
    

• 做有意义的区分

  • 避免使用数字系列命名来做变量间的区分。例如 a1、a2、a3，糟糕的一批，纯属搅混水。
  • 避免废话，更避免冗余废话。比如你命名的理由就是因为有了 a 和 b，于是你不得不将下一个命名命为 c。例如 ProductData 和 ProductInfo，冗余废话就像 NameString

• 尽量用能搜索出来的名字（方便缩小全局搜索的结果）。尽量让名称长度与其作用域呈正相关关系，比如对于在局部使用的变量，你可以命名短一点，但是如果是全局使用的常量，你最好用一个能方便搜索且有区分度长度适中的名称

3、 类名

• 类名和对象名应该是名词或者名词短语，而不应该是动词。

4、 方法名

• 方法名应该是动词或者动词短语

• 属性访问器、修改器、断言应该和其值有关系，例如 getName()、setName()、isPaid()

• 重载构造器的时候，可以考虑使用描述了参数的静态工厂方法名，如下

  •   Complex point = Complex.FromRealNumber(23.0) 
      Complex point = new Complex(23.0)
    

  • 为了规范使用这种多个重载构造器的方法，你甚至可以 private complex 的默认构造器，不让使用者采用 new 的方式来创造实例

5、 每个通用概念对应一个词，避免双关

• 给每个抽象概念选一个词，并且一以贯之。
  • 例如 fetch、retrieve、get 选一个，而不是到处混用
  • 假设在一堆代码中有 controller、又有 manager，那区别到底是什么呢？编写者当然很清楚，但是看代码和使用代码的后继者需要付出更高的成本来在需要的时候来进行区分
• 避免同一单词用于不同目的，同一术语用于不同概念
  • 但是保持一致的度，需要把握好，必须是真的“一致”。例如 add 这个词的抽象语义通常表达为增加两个现存值来获得新值。比如现在要写一个新类，为该类设计一个方法，将某个元素放到集群之中（collection），那这个函数名应该为 add 来保持 ”一致“ ？显然考虑到其抽象语义，用 insert 和 append 更好！

6、使用解决方案领域名称

• 记住，只有程序员才会读你的代码，而且读代码者通常是协作者。在编写代码的时候，应该让名字与其解决方案有关，不应该搞一些专用的乱七八糟的术语，让命名显得更 ”正规“，导致在开发过程中，协作者需要经常问编写者其含义谓何。

7、添加语境，避免无意义的语境

• 大多数情况下，单个单词在没有语境和上下文的情况下是无法表达出其所在的代码块所表达的含义（系统思维中局部和系统之间的相对关系构建出了局部的含义）。当代码块中的语境不够明显时，可以改写写法来增强语境，例如增加命名空间、一系列有意义且相互联系的数字或者字符串用枚举来表示
• 当然有时候也需要避免没有意义的语境，例如你给一个英雄类的各个属性字段叫 HeroAttack、HeroDefense。冗余信息太多了！

8、最后

• 精确的命名很难通过一次思考得出，不要害怕改名，每一次合理的重构名字都会让代码的命名更加贴切，更加合理。所以请在有必要的时候来改写代码中的命名，让它更加精确。

• 上面的很多规则并不是并行的，很多时候甚至有冲突，需要在考虑好需求的情况下合理遵守