编写可读代码的艺术

代码是程序的起源

程序最基本的元素便是代码，无论任何开发语言。优雅的代码利于程序员之间的沟通，也更能写出更好的程序。本篇文章就是希望作为一名合格的开发攻城狮，应具有不断优化代码的意识。下面内容来源于《编写可读代码的艺术》一书，是本人看完后的一些知识提炼，有兴趣的同学可以去看这本书哟。

第一章：代码应当易于理解

可读性基本定理：代码的写法应当使别人理解它所需要时间的最小化

第二章：把信息装到名字里

主题：

1. 使用专业的单词
2. 避免使用空泛的名字
3. 用具体的名字描述更细致的事务
4. 给变量名加上重要的细节
5. 作用域大的应该用更长的名字
6. 有目的的使用大小写，下划线等

第三章：不会误解的名字

主题：

1. 不会误解的名字，不会有较多其他的意思
2. 定义一个上限或者下线是，用max_和min_的前缀，定义包含范围的，用first和last会比较好，定义包含/排除范围，用begin和end是好的选择
3. 定义布尔类型的，避免使用反义词
4. 要小心用户对特定词的期望，比如他们认为get()和sieze()是轻量级的行为

第四章：审美

主题：易读好看的代码有三条原则

1. 使用一致的布局，让读者很快的习惯这种风格
2. 让相似的代码看上去是相似的
3. 把相关的代码进行分组，形成代码块

第五章：该写什么样的注释

主题：
一、什么地方不需要注释

1. 能从代码本身中迅速地推断的事实
2. 用来粉饰烂代码的“拐杖式注释”—应该把代码写好

二、你应该记录下来的想法包括

1. 对于代码写成这样而不是那样的内在理由
2. 代码中的缺陷，使用像TODO：或者xxx：这样的标记
3. 常量背后的故事，为什么是这个值

三、站在读者的立场上思考

1. 预料到代码中哪些部分会让读者说：“啊？”并且给它们加上注释。
2. 为普通读者意料之外的行为加上注释
3. 在文件/类的级别上使用 “全局观”注释来解释所有的部分是如何一起工作的。
4. 用注释来总结代码快，使读者不至致迷失在细节中。

第六章：写出言简意赅的注释

主题：

1. 避免使用指代多个事物的代词
2. 尽量精确地描述函数的行为
3. 在注释中添加简单的输入/输出例子进行说明
4. 声明代码的高层次意图，而非显示的细节
5. 用嵌入的注释来解释难易理解的函数参数
6. 用含义丰富的词来使注释简洁。

第七章：把控制流变得更易读

主题：

1. 在写一个比较时if（a > b），把改变的值写在左边，更稳定的值写在右边。
2. 在if/esle语句中的语句块，通常先处理正确的/简单的/有趣的情况。
3. 三目表达式不宜放过多计算表达式。
4. 使用线性的代码来避免深嵌套。
5. 通常提早返回可以减少嵌套并让代码整洁。

第八章：拆分超长的表达式

主题：

1. 引入“解释变量”和“总结变量”来代表较长的子表达式。
2. 用徳摩根定理来操作逻辑表达式。

第九章：变量与可读性

主题：

1. 减少变量：消除多余的中间变量
2. 减小每个变量的作用域
3. 只写一次的变量更好：常量易理解，也不会有问题

第十章：抽离不相关的子问题

主题：

1. 把一般代码和项目专有的代码分开
2. 创建大量的通用代码和工具类代码

第十一章：一次只做一件事

主题：一次只做一件事，也就是把一个流程细分成具体的小事

第十二章：把想法变成代码

主题：用自然语言描述程序，描述事情，然后写出更自然的代码。

第十三章：少些代码

主题：

1. 从项目中消除不必要的功能，删除没用的代码，不要过度设计
2. 重新考虑需求，解决版本最简单的问题，能完成工作就行
3. 经常性的通读标准库的整个API，保持对它们的熟悉程度

第十四章：测试与可读性

主题：

1. 每个测试的最高一层应该越简明越好，最好每个测试的输入/输出可以用一行代码描述
2. 如果测试失败了，它发出的错误消息应该能让你容易跟踪并修改这个bug
3. 使用最简单的并且能够完整运行代码的测试输入
4. 给测试函数取一个有完整性描述的名字。

最后

本篇内容来自《编写可读代码的艺术》一书，我们需要尊重作者的知识成果，有兴趣的同学可以去购买观看这本书。这篇文章若有侵权或者违反相关规定，请马上联系本人！谢谢！