《编写可读代码的艺术》—— 读后总结
本书与代码整洁之道类似，强调的不是编程的技巧，而是代码编写的注意点。
有的开发者可能觉得自己的代码自己懂就比较好，不在乎变量和函数的命名以及缩进等等，但是这里的别人也可能是几个月后的自己！
因此，代码的可读性对于别人和自己都很重要。
本文内容
本书短小精悍，相比于《代码整洁之道》要薄的多，但是要注意的地方，基本也都讲明白了：
本书的主要内容如下：
有时候并不是代码越少，就越容易理解，也许多写几行代码比如三目运算符?和if/else，他们可以写出相同的逻辑，但是如果表达式很长，三目运算符显然更不容易理解和调试，所以按照实际的情况进行代码的编写，才能提高可读性，没有过多硬性的要求，一切以可读性为基准。
因此总结起来，就是要写出简要的代码，表达关键的思想，使其他人用最快的速度理解。
同样的，评判一段代码的可读性良好，就可以通过别人理解这段代码的时间来衡量。
表面改进
首先最基本的就是变量和函数的命名，尽量选择专业的词汇、避免泛泛的名字（如it,attr等等）、用具体的名字代替抽象的名字、使用前缀或后缀来附带更多的信息、名字的长度、利用名字格式表达含义。
另外用于短期存在或者临时性的变量可以使用类似tmp这种变量名。
因此总结起来，花点时间好好想想名字，比多写写注释要强得多，时刻注意：好的名字>坏名字+好注释
1 使用专业的词汇
2 避免空泛的名字
3 使用具体的名字来更细致的描述事物
4 给变量名带上重要的细节
5 为作用域大的名字采用更长的名字
6 有目的的使用大小写、下划线等等。
另外也应该注意代码的布局：
1 如果代码块想死，尝试构造成相似的写法。
2 把代码对齐，更容易浏览。
3 如果一段代码中组织形式是ABC，另一端中不要CBA颠倒顺序。
4 用空行分割大段的代码。
最后关于注释，需要了解什么不需要注释，用代码记录你的想法，站在读者的角度想象他们在阅读时是如何思考的。
而对于那些快速可以推断的，或者用于说明烂代码的都不需要注释。烂代码还是要修其命名，使之优美。
在注释中，要注意一下的问题：
1 避免使用it，this有歧义的单词
2 精确描述函数行为
3 在注释中，写入精心挑选的样例
4 生命代码高层次的意图，而非明显的细节
5 用嵌入的注释解释难以理解的参数
6 用含义丰富的词来使注释简洁
简化逻辑
在编写业务逻辑代码时：
1 在写一些逻辑时，尽量不要一次性写入过多的逻辑，可以通过提取工具性的代码，缩短函数。
2 在做if/else判断时，尽量先写主要的逻辑代码。
3 三目运算符，dowhile goto都会降低可读性。尽量避免，如果表达式很短，可以考虑使用三目运算符
4 减少逻辑嵌套
5 提早返回。在做一些边界检查和安全性编写时，提前返回。
在有过长的表达式中，可以按照下面方法简化:
1 把巨大的表达式拆分成小段
2 引入解释变量，通过简单的中间变量代替很长的表达式。
3 识别主要的业务逻辑。
关于变量要注意：
1 变量越多，越难跟踪变量的动向。
2 变量作用域越大，跟踪它的动向越久
3 变量改变越频繁，越难跟踪其当前值。
组织代码
尽量抽取不相关的子问题，整理成工具代码，编写多用途代码，创建通用代码。
简化逻辑代码，把一般代码与项目专有代码分开，让代码尽量只剩下核心业务逻辑，其他的一般代码都整理到相关工具类中。
尽量保证一个方法只做一件事情，过多的任务耦合在一起，一方面不利于代码的阅读，在处理调试时，也容易混乱。
使用自然语言描述，网上有个“橡皮鸭技术”。就是用自己的话描述一下这段代码，这时候你会更明白这段代码的核心作用。
如果对别人也能用自然语言简单的讲述，那么代码也会围绕这些语言做最简单的编写，不会有太多无用的部分。
尽量少些代码，多阅读项目以及API中已有的函数方法，消除不必要的功能，不要过度设计。
首先解决版本最简单的问题，只要能完成工作就行，这部分的作用占整个代码的80%，就是28原则。
最后经常阅读API，保证当使用的时候能有印象已经存在这种功能就可以了，避免自己做过多的无用功。
其他话题
对于测试来说，可读性也很重要。
因为很多程序员都把测试当做半个文档来使用，而这个时候测试驱动TDD开发，就显得很有优势了。
在编写测试时：
1 尽量简化输入输出
2 提示的错误信息保证能够快速的定位问题，修正BUG
3 简单并且能完整运用测试输入
4 测试函数也需要完整性描述名字。
