编写可读代码的艺术-读书笔记
最近读这本书，总体感觉作者很实在，通过一个一个的小细节，诠释了可读代码的衡量情况。
代码应当易于理解
- 代码的写法，应当便于别人理解它需要的时间最小化
把信息装入名字中
- 选择专业的词，避免使用空洞的词
- 找到更有表现力的词
- 避免像tmp这样的范范的名字
- 像i、j等名字常用做索引或者迭代器，尽管空泛，但是大家都知道他的意思
用具体的名字代替抽象的名字
- 使用具体的名字来更细致的描述事物
- 给变量带上更重要的细节（例如在值为毫秒的变量后面加上_ms）
- 为作用域大的名字采用更长的名字，不要用让人费解的一个或者两个字母的名字来命名几屏之间都可见的变量
- 有目的的使用大小写和下划线等
使用不会被误解的名字
- 推荐用min和max来表示极限的情况
- 推荐使用first和last来表示包含的范围
- 推荐用begin和end来表示包含和排除范围
- 给boolean值命名加上is、has、can会更加易于理解
- boolean 这一类，避免使用反义名词（例如disable_ssl=false不如use_ssl=true）
代码的审美
- 使用一直的布局，让读者很快就能习惯这种风格
- 让相似的代码看上去相似
- 把相关的代码进行分组，形成代码块
- 重新安排换行来保持一致和紧凑（例如构造函数中多个参数）
- 用方法来整理不规则的东西
- 在需要的时候使用列对齐
- 把代码按照业务含义分成“段落”
- 个人风格的一致性
- 一致的风格比“正确”的风格更重要
什么情况不需要注释
- 不要为了那些从代码本身就能快速推断的事实写注释
- 不要为了注释而注释
- 不要给不好的名字加注释，应该把名字改好
用注释记录你的思想
- 对于为什么代码写成这样而不是那样的内在理由
- 代码中的缺陷，使用TODO或者XXX来进行标记
- 常量背后的故事，为什么是这个值
站在读者的立场上思考
- 预料到代码中哪些部分会让读者不理解，这时候需要添加注释了
- 为普通读者意料之外的行为加上注释
- 在文件或者类级别上使用全局观的注释来解释
- 用注释来总结代码块，是读者不致于迷失在细节中
把控制流变得易读
- 条件语句的参数顺序（比较的右侧，用来比较的表达式，更加倾向于常量）
- if/else中，首先处理正逻辑而不是负逻辑，优先处理简单的情况，先处理有趣或者可疑的情况
- 默认情况下使用if来进行判断，三目运算符在最简单的情况下使用
- 避免使用do/while循环，因为while循环相对更加易读，先条件后代码块
- 嵌套的代码块需要更加集中精力去理解，每层新的嵌套都需要读者把更多的上下文信息带入，应该把他们改成更加线性的代码来避免深嵌套
- 通常来讲，提早返回可以减少嵌套并让代码整洁
拆分超长的表达式
- 一个简单的技术是引入“解释变量”来代表较长的子表达式，这样可以把巨长的表达式拆成小段，读者更加容易理解代码中的主要概念
- 德摩根定律来操作逻辑表达式（例如if(!(a && !b))）改为 if(!a || b)
变量与可读性
- 减少变量，消除没用的“中间结果”
- 减少每个变量的作用域，越小越好
- 只写一次的变量更好
重新组织代码
- 把一般的代码和项目专有的代码分开
- 组织代码的简单技巧，一次只能做一件事情
- 用自然语言描述程序，然后用这个描述来帮助你写出更加自然的代码
少写代码
- 从项目中消除不必要的功能，不要过度设计
- 经常性的通读标准库的整个API，保持对他们的熟悉程度