本篇文章基于本人从事IT行业四五年后，阅读《编写可读代码的艺术》《The art of Readable Code》一书的读书感悟。
如果你从业不足一两年，那本书比较适合你，如果已经从业三年及以上，你本应该掌握以下技术要点和意识。
电子图书地址：https://yuedu.baidu.com/ebook/45a7456bfc4ffe473268ab44?fr=aladdin&key=编写可读代码的艺术
前言：
基本是吹一波彩虹屁，感谢铁岭TV、辽宁TV、CCTV啥的..
第一章：
说下这本书的目的和经过，再剩下就是传达一个信号，
去粗取精、细嗅蔷薇是优秀工程师应有的工作态度，自律、自由、效率应是我们的工作追求！
创造极佳的工作体验，从自我做起！
第二章 把信息装到名字中
1.命名内容-单词替换
Senddeliver、dispatch、announce、distribute、route
Findsearch、extract、locate、recover
Startlaunch、create、begin、open
Makecreate、setup、build、generate、compose、add、new
2.命名格式-前缀后缀
Start(int delay)delay_secs
CreateCache(int size)size_mb
ThrottleDownload(float limit)max_kbps
Rotate(float angle)degrees_cw
3.使用专业、精准的单词，凸显你的专业性，如1，2
4.尽量避免空泛的命名单词，如tmp、retval、result等
5.使用具体的命名来更细致地描述事物，isServerOnPort()比ServerCanStart()更加细致优雅
6.给变量名带上重要的细节-例如延迟毫秒数命名delay_ms，未处理的变量前添加前缀raw_
7.作用域更大，可采用更长的命名
8.团队内部使用同一规范和目的地使用大小写下划线等，例如类成员和局部变量可后缀添加”_”来区分
第三章 不会误解的名字
一个中心思想，以新手的心态来看你的代码的心态来写代码，别让你的代码有二义性！！！
第四章 审美
一致性的风格比风格“正确”更重要
1.如果多块代码在做相同的事情，尝试抽成公共方法
2.代码按“列”对其，可让同伴浏览代码的体验极佳
3.如果在一段代码中次序为A、B、C，那么在另一端代码中，需要的话，次序也应为A、B、C
4.使用空行隔开大块代码，形成段落
第五章 该写什么样的注释
注释不仅是在解释代码做了什么，更多的目的是确保读者与作者了解的一样多
1.不要写一些可通过方法名、参数名、类名等就可以快速推断得到的信息
2.不要为了写注释而写注释
3.注释不应是在解释命名的二义性，或掩饰命名的缺点与缺陷，该改命名就去改命名！好代码>坏代码+好注释
第六章 写出言简意赅的注释
1.多个名词出现，请不要使用it或this等代词
2.尽量精确描述函数的操作行为
3.可使用精简的输入/输出例子进行说明
4.声明代码的高层次意图，而非明显细节
5.多函数可在调用时，使用嵌入参数式进行编写注释，（IDE工具可显示形参名称除外）
6.使用饱满丰富的单词来使注释简洁
第七章 把控制流变得易读
1.改动代码需要站在整体角度来审视if-else嵌套，最好使用线性代码
2.if判断中，变量在左，常量在右
3.if逻辑语句中最好不要使用双重否定
4.慎用三目运算
第八章 拆分超长的表达式
1.充分利用德摩根律，必要时可反向取补集思维
2.if中最好判断次数较少
3.必要时可使用宏
4.必要时可创建临时变量
第九章 变量与可读性
1.如果可以，减少变量
2.如果可以，减少变量的作用域
3.如果可以，使用常量
第十章 抽取不相关的子问题
1.重复代码请抽方法
2.估计抽象出新的方法，但也需要防过犹不及
3.抽象出的方法的操作保持同一个抽象层次上
4.保持抽象出的操作具有对称性
5.慎用递归（考虑递归出口与栈深度）
第十一章 一次只做一件事
难的是要准确地描述你的程序所做的所有这些小事情
第十二章 把想法变成代码
如果你无法清晰地将代码大道至简表述出来，那么你必然是缺少了对某些东西的定义。
第十三章 少写代码
1.反刍需求的细节，减少非必要feature，减少过度设计
2.尊重需求/代码的完整周期（一般特指最后的死亡态，进行代码净化与删除工作）
3.能复用的，就尽可能去复用（项目中的工具类、各种开源库、源码API等）
4.无事可做可通读标准库API
第十四章 测试与可读性
1.测试应该简明、每个测试输入输出，仅用一行代码体现，效果极佳
2.如果测试失败，理应暴露必要充足的错误消息
3.测试在保持简明条件下，应对代码做分支、场景的完整性验证
4.规范测试函数的命名。要求与业务函数可区分性、与业务函数的顺承性，也包含对业务函数的测试条件表达
（例如，Test_<FunctionName>_<Situation>）
5.确保测试的易于改动与新增
第十五章 设计并改进“分钟/小时计数器”
本章使用了上述的招式，讨论了三种设计方案的优缺点。
感触更多的是，要保持其他人对自己代码态度的开放心态，因为其他人，很可能包含6个月之后的自己！
