代码整洁之道（1）
代码整洁之道（1）
引言
短短的两个月内，陆续的上手了两个规模还算大的前端和后端项目，其实两边都算是刚入门的水平，开发过程中其实也感受到了不少代码整洁所带来的好处。后端由于是有大佬带 + SpringBoot的后端项目结构很规范，所以类间关系的抽象和设计其实没遇到很大的问题，但是对于具体方法的实现，其实在代码的维护和可读性上还是遇到了一定的问题的。这个问题到了前端开发时问题就更加明显了，自己从零设计一个完整的项目耗费了我很大的精力，而且项目结构并不是很规范，在开发时其实翻来覆去重构了很多次，现在基本实现了功能的代码也有很多的“负债”。不管是组件间的抽象还是方法的抽象，都有很大的问题，所以愈发觉得这本书的意义之深。所以写下这个系列来记录一下这本书的学习过程。 ——2022/9/10
有意义的命名
名副其实
变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充，那就不算是名副其实。
在修改完命名后，我们能够通过变量名很容易的理解代码的语义。如果觉得使用int数组不够优雅且还不够直观，还可以自定义一个类来包裹它。
只要简单改一下名称，就能轻易知道发生了什么。这就是选用好名称的力量。
避免误导
程序员必须避免留下掩藏代码本意的错误线索。应当避免使用与本意相悖的词。
如相似的名称依字母顺序放在一起，且差异：很明显，那就会相当有助益，因为程序员多半会压根不看你的详细注释，甚至不看该类的方法列表就直接看名字挑一个对象。
做有意义的区分
如果程序员只是为满足编译器或解释器的需要而写代码，就会制造麻烦。光是添加数字或是废话远远不够，几遍这足以让编译器满意。如果名称必须相异，那其意思也应该不同才对。
如果参数名改为source 和destination, 这个函数就会像样许多。
废话是另一种没意义的区分。假设你有一个Product 类。如果还有一个Productlnfo或ProductData类，那它们的名称虽然不同，意思却无区别。
废话都是冗余。Variable 一词永远不应当出现在变量名中。Table 一词永远不应当出现在表名中。
使用读得出来的名称
人类长于记忆和使用单词。大脑的相当一部分就是用来容纳和处理单词的。单词能读得出来。人类进化到大脑中有那么大的一块地方用来处理言语，若不善加利用，实在是种耻辱。
使用可搜索的名称
单字母名称和数字常量有个问题，就是很难在一大篇文字中找出来。名称长短应与其作用域大小相对应。
使用变量来代表某些常量，一定程度上能够增加代码的可读性，修改常量时也能直接搜索到。
避免使用编码
把类型或作用域编进名称里面，徒然增加了解码的负担。
现代编程语言具有更丰富的类型系统，编译器也记得并强制使用类型。而且，人们趋向于使用更小的类、更短的方法，好让每个变量的定义都在视野范围之内。
也不必用m_前缀来标明成员变量。应当把类和函数做得足够小，消除对成员前缀的需要。你应当使用某种高亮或用颜色标出成员的编辑环境。
避免思维映射
不应当让读者在脑中把你的名称翻译为他们熟知的名称。这种问题经常出现在选择是使用问题领域术语还是解决方案领域术语时。
聪明程序员和专业程序员之间的区别在于，专业程序员了解，明确是王道。专业程序员善用其能，编写其他人能理解的代码。
类名
类名和对象名应该是名词或名词短语，如Customer、WikiPage 、Account 和AddressParser。避免使用Manager、Processor、Data 或Info 这样的类名。类名不应当是动词。
方法名
方法名应当是动词或动词短语，如postPayment 、deletePage 或save 。属性访问器、修改器和断言应该根据其值命名，并依Javabean 标准1加上get、set 和is 前缀。
别扮可爱
扮可爱的做法在代码中经常体现为使用俗话或俚语。言到意到。意到言到。
每个概念对应一个词
给每个抽象概念选一个词，并且一以贯之。
函数名称应当独一无二，而且要保持一致，这样你才能不借助多余的浏览就找到正确的方法。
别用双关语
避免将同一单词用千不同目的。同一术语用千不同概念，基本上就是双关语了。
使用解决方案领域名称
记住，只有程序员才会读你的代码。所以，尽管用那些计算机科学(Computer Science, CS)术语、算法名、模式名、数学术语吧。依据问题所涉领域来命名可不算是聪明的做法，因为不该让协作者老是跑去问客户每个名称的含义，其实他们早该通过另一名称了解这个概念了。
添加有意义的语境
很少有名称是能自我说明的——多数都不能。反之，你需要用有良好命名的类、函数或名称空间来放置名称，给读者提供语境。如果没这么做，给名称添加前缀就是最后一招了。
不要添加没用的语境
只要短名称足够清楚，就要比长名称好。别给名称添加不必要的语境。
/fm.png)
