前段时间看了 Bob 大叔的《代码整洁之道》英文名 clean code ，结合自己的学习经验，对代码整洁的重要性有了⼀些新的理解与感悟。遂在此做笔记，大家共同探讨，共同学习。
# 前言
书中 Bob 大叔提倡 "写代码犹如写文章" ，又说道 “大师级程序员把系统当故事来讲，而不是当做程序来写 ” 。没错，好的代码就应该如好文章一样表达思想，被人读懂。
这本书如其名，教我们如何写出整洁的代码，以及写出整洁代码的理念。足够好的命名，简单专注的函数，有意义的注释以及规范的代码格式。比如如何命名（命名太难了😢）、如何处理异常、怎么写好易读的类和方法等等。
# 什么是整洁的代码？
作者采访了一些知名的程序员，对于这个问题每个人都有不同的定义：
- “我喜欢优雅和高效的代码...” --Bjarne Stroustrup
- “整洁的代码简单直接...” --Grady Booch
- “整洁的代码总是看起来像是某位特别在意它的人写的，几乎没有改进的余地...” --Michael Feathers
- “如果每个例程都让你深合己意，那就是整洁代码...” --Ward Cunningham
- 等等。。。
看了上面几位知名程序员的话，感觉还是有点抽象。不还还算是有点眉目了。那么我们日常开发该如何写出这样的代码呢？
# 如何才能写出整洁代码呢？
简单总结一下就是 KISS（ Keep It Simple Stupid ）：让代码简单直接，让阅读代码的人可以很容易地看出设计者的意图。
书中给出了很多方法与规范，学习这些规则可以帮我们写出更加的整洁代码。下面总结一些我印象比较深刻的内容 结合我的理解分享给大家。
# 有意义的命名
认证对待每个变量名，应当用为自己第一个孩子命名般的谨慎来给变量命名。
- 名副其实：选一个好名字，也许会花费很多的时间，但省下来的时间比花掉的多，我们读和写的比例是远远大于 5:1 的。而且一旦发现有其他更好的名称，就换掉旧的。
- 做有意义的区分：不要定义，没有提供正确信息，没有提供导向作者意图的线索的命名。
- 名称：使用读得出来的名称，使用可搜索的名称。名称的长短应与其作用域大小相对应。
- 类名：类名和对象名应该是名词或名词短语，如 Customer 和 Account。避免使用 Manager、Data 或 Info 这样的类名。不应当是动词。
- 方法名：方法名应当是动词或动词短语，如 postPayment、deletePage 或 save。
- 别用双关语：不要将同一个单词用于不用的目的。
我们的代码不仅是写给自己看的，更是写给别人看的，有意义的命名是提高表达力的一种方式。时刻保持代码整洁，是对自己负责也是对团队负责。
# 简单专注的函数
函数的第一条规则是短小，第二条规则是还要更短小。
- 只做一件事：函数应该做一件事，做好这一件事，只做这一件事。
- 每个函数一个抽象层级：这一条比较难理解，就比如将大象装进冰箱一样，可以分为 3 个步骤
开门->装大象->关门。而在装大象之前需要进行判断冰箱的大小和大象的大小以及冰箱中是否有其他东西，那么 3 大步骤是一个层级的，其余的这些判断第二层级，还可能有第三层级。简而言之，就是分层。 - switch 语句：尽量少用，switch 语句本身就是用来处理多件事的，而用抽象工厂可能会更好一点。
- 描述性的名称：长而具有描述性的函数名称，好过描述性的长注释。
- 函数的参数：零参数最好，其次是一个参数，再次是二个参数，应尽量避免三个参数。
- 无副作用：不要把另外一件事隐藏到这个函数中，避免函数做不在名称描述中的第二件事。
写代码很像是写文章。先想什么就写什么，然后再打磨： 分解函数、修改名称、消除重复 。一开始编写的代码或许冗长而复杂，最后经过打磨会变的短小，并且被很好的归置。
# 注释
＂别给糟糕的代码加注释 —— 重新写吧。＂ —Brian W. Kernighan 与 P. J. Plaugher
- 注释不能美化糟糕的代码；
- 注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。
- 代码可以表达清楚的事情，就不要用注释。
- 与其花时间编写解释你写的糟糕的代码的注释，不如花时间清理那堆糟糕的代码。
为什么这里要极力贬低注释？
因为注释会撒谎。注释存在的时间越久，就离其所描述的代码越远，越来越变得有误导性。原因很简单：我们维护项目的时候，不能坚持维护注释。代码在变动、在演化，但是注释并不总是随之变动 —— 不能总是跟着走。
PS：不知道有没有小伙伴和我一样，单纯的认为 “所有的方法都必须写注释”。然而大部分的注释就是简单的把方法名翻译一遍，我们自己可能感觉没什么，但是对于下一个阅读我们代码的人来说 阅读时间就需要乘以二（和我一起改掉这个不好的习惯吧～）。如果我们决定要写注释，就要花必要的时间确保写出最好的注释。
# 单元测试
整洁测试三要素：可读性、可读性、可读性
说到测试就有必要说一下著名的 TDD 了。
TDD 三定律
TDD 是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。
- 定律一 在编写不能通过的单元测试前，不可编写生产代码。
- 定律二 只可编写刚好无法通过的单元测试，不能编译也算不通过。
- 定律三 只可编写刚好足以通过当前失败测试的生产代码
大家都知道 TDD 要求我们在编写生产代码前先编写单元测试。但这条规则只是冰山之巅。
编写单元测试虽然很花费时间，但是好处还是很显而易见的：
- 单元测试好处：保持生产代码可扩展、可维护、可复用。
- 有了测试，我们就不用担心对代码的修改。
- 测试代码可以降低性能的要求、来追求可读性。
整洁的测试还遵循以下 5 条规则：
- 快速（Fast） 测试应该够快。测试应该能快速运行。
- 独立（Independent） 测试应该相互独立。某个测试不应为下一个测试设定条件。
- 可重复（Repeatable） 测试应当可在任何环境中重复通过。
- 自足验证（Self-Validating） 测试应该有布尔值输出。无论是通过或失败，你不应该查看日志文件来确认测试是否通过。
- 及时（Timely） 测试应及时编写。单元测试应该恰好在使其通过的生产代码之前编写。
关于简洁代码相关内容就先介绍到这里。有什么问题大家一起讨论
# 结尾：
艺术书并不保证你读过之后能成为艺术家，只能告诉你其它艺术家用过的工具、技术和思维过程。
最后，再送给大家一些书中我比较喜欢的话：
质量是上百万次全心投入的结果。
细节之中自有天地，整洁成就卓越代码。
全心倾注于细节，屡见于追求卓越的行为之中。
🚀🚀🚀
