《整洁代码之道》学习书摘（三）第二章——有意义的命名

版权声明：本文为博主原创文章，愿转就转吧~ https://blog.csdn.net/slx3320612540/article/details/82085421

第二章 有意义的命名

介绍

1. 软件中随处可见命名，我们给变量、参数、类、包命名，我们给源代码以及它所在的目录命名。我们命名，命名，不断的命名。既然有这么多命名要做，不妨做好它；

名副其实

1. 选个好名字要花时间，但是省下来的时间比花掉的多；
2. 变量、函数或者类的名称应该已经回答了所有的大问题。它该告诉你，它为什么会存在，它做什么事，该怎么用，如果名称需要注释来补充，那么就不算是名副其实；
3. 问题不在于代码的简洁度，而是在于代码的模糊度：上下文在代码中未被明确体现的程序；
4. 只要改为有意义的名称，代码就会得到相当程度的改进；这就是选用好名称的力量；

避免误导

1. 程序员必须避免留下掩饰代码本意的错误线索；
2. 应当避免使用与本意相悖的词，比如不要使用accountList作为一组账号的名称，除非它真的是List，不妨使用accountGroup等；
3. 提防使用不同之处较小的名称（有着过长的相同前缀，这类词往往让人不容易区分）；
4. 以同样的方式拼写出同样的概念才是信息；

做有意义的区分

1. 如果程序员只是为了满足编译器或者解释器的需求而写代码，就会制造麻烦；
2. 名称应该提供正确的信息，提供导向作者意图的线索；
3. X-Info和X-Data就像a、the、an一样，是含义混淆的废话；
4. 废话都是冗余。Variable一词永远不应当出现在变量名中；
5. 要区分名称，就要以读者能够鉴别不同之处的方式来区分；

使用读得出来的名称

1. 人类长于记忆和使用单词，人类进化到大脑中有一块区域用来处理语言，如果不善加利用，实在是一种耻辱；
2. 如果名称读不出来，讨论的时候就会像个傻鸟；
3. 编程本身就是一种社会活动；

使用可搜索的名称

1. 单字母名称和数字常量有个问题，就是很难在一大篇文字中找出来；
2. 单字母名称仅用于短方法中的本地变量。名称长短应该与其作用域大小相对应；
3. 长名称胜于短名称，搜索得到的名称胜于用自造编码代写就的名称；

避免使用编码

1. 编码已经太多，无谓再自找麻烦；
2. 把类型或者作用域编进明成立满，徒然增加了解码的负担，没有利用要求每位新人在弄清楚要应对的代码之外还要再搞懂另一种“编码”语言；
3. 再往昔名称长短很要命的时代，我们毫无必要地破坏了不编码的规则，如今后悔不迭；
4. HN（匈牙利语标记法）和其他类型的编码形式都纯属多余，它们增加了修改代码的难度（比如，修改函数、变量或者类的名称或者类型）。它们增加了阅读代码的难度；
5. 应当把类和函数做的足够小，消除对成员前缀的需求；
6. 代码读得越多，眼中就越没有前缀，最终前缀变成了不入眼的废料，变成了旧代码的标志物；
7. 前导字母I被滥用到说好听一点是干扰，说难听点根本就是废话的程度。我不想让用户知道我给他们的是接口。

避免思维映射

1. 不应该让读者在脑中将你的名称翻译为他们所熟悉的名称；
2. 聪明程序员和专业程序员之间的区别就在于，专业程序员了解，明确是王道。专业程序员能善用其能，编写其他人可以理解的代码；

类名

1. 类名和对象名应该是名词或者名词短语，不应当是动词；

方法名

1. 方法名应该是动词或者动名词；
2. 使用带参数的静态工厂方法来替代构造函数，因为构造函数无法也不应该表现其接受的参数类型；可以使用private 修饰构造函数以强制使用这种命名手段；

别扮可爱

1. 言到意到，意到言到；

每个概念对应一个词

1. 对于那些会用到你代码的程序员，一以贯之的命名法简直就是天降福音；

别用双关语

1. 避免将同一单词用于不同目的；
2. 代码作者应尽力写出易于理解的代码，让别人能一目尽览，而不必殚精竭虑的研究；
3. 依据问题所涉及领域来命名可算不上聪明的做法；

使用解决方案领域的名称

1. 程序员要做太多技术性工作，给这些事取个技术性的名字，通常是最靠谱的事；

使用源自问题领域的名称

1. 如果不能用程序员熟悉的术语来给手头工作命名，就采用从所涉及的问题领域而来的名称；
2. 优秀的程序员和设计师，其工作之一就是分离解决方案领域和问题领域的概念；
3. 与所涉及问题领域更贴近的代码应该使用源自问题领域的名称；

添加有意义的语境

1. 很少有名称是能自我说明的，你需要用有良好命名的类、函数或者名称空间来放置名称，给读者提供语境；
2. 语境的增强让算法能够通过分解为更小的函数而变得更为干净利落；

不添加没有用的语境

1. 只要短名称足够清楚，就要比长名称好，别给名称添加不必要的语境；
2. 精确正是命名的要点；

最后的话

1. 取好名称最难的地方在于需要良好的描述技巧和共有的文化背景；
2. 如果名称能改的更好，大家真的会感谢你；

学习收获

命名是编程中无法避免的一个环节，我们通过命名给来表述我们对需求的理解；命名之所以重要，是因为我们是作者，我们所编写的代码不仅仅由机器执行，还将由人维护；有意义的命名至关重要，但是我们该如何让命名有意义？更重要的是，我们需要让别人觉得有意义而不是自己觉得有意义就ok了。
我想，编码参数——将类型、作用域等信息作为命名的一部分，在一定程度上让命名有了意义，但是，这种意义是建立在大家对这种表示方法有着一致的理解过程——对于编程老手来说，自然问题不大，实际上，对于老手看起来比较友好，是因为他们已经“交过学费了”，但是对于新手来说，仍旧不友好——新手在理解项目工程逻辑以及设计理念上应该投入更多的精力，当然，这些是基于能理解代码的基础，然而，能理解代码表明需要理解他人的这种表示方法——即，你必须先熟悉这种表达机制，才能入手代码，尽管这种表达机制和项目本身一点关系也没有，你也得投入精力！这很不友好！就像，我约定，yes表示否定，no表示肯定——不论yes还是no都是一种表达意思的方法，这么做当然可以，只有你知道我的这种规定，就可以理解我的表述。然而，理解是一回事，方便地理解又是另一回事了。我想这就是作者抛弃编码命名的理由了。
当然，上面也指出了我习以为常的一种做法：使用I作为接口的前导字母，额，另一种编码变量的形式！其实这样的话，就要求使用者知道某一个以I开头的东东是一个接口，但是作为使用者来说，他不需要知道他正在使用的是接口还是抽象类，他只需要关注功能！无疑，这给使用者增添了额外的麻烦，虽然当阅读者看到IRobot可以清楚地知道这是一个机器人接口；
所以，有意义的命名其背后是一种让他人舒服的理念~不管我们是使用问题领域的名称还是解决方案邻域的名称，只要让我们潜在的服务对象可以舒服地阅读我们的代码，我们就是成功的！好像是一种“我为人人，人人为我”的“大同社会”哦！