编写可读代码的艺术——读后感

第一部分 表面层次的改进

可读性代码的改进从 表面层次 的改进开始：选择好的名字、写好的注释、代码整洁的写成更好的格式。

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

无论是命名变量、函数还是类，都有很多相同的原则，尝试把名字当成一个小小的注释语句，选择一个好的名字，让其承载更多的信息。

• 选择专业的词

  假设你有个Thread类：

  class Thread{
      void Stop();
  };
  

  Stop其实还可以，但是如果该线程不能恢复，使用Kill应该更好一些

• 找更有表现力的词

  下面列出一些表现力更强的单词，依语境采用：

  send -> deliver 、 dispatch 、 announce 、 distribute 、 route
  find -> search 、 extract 、 locate 、 recover
  start -> lanch 、 create 、 begin 、 open 
  make -> create 、 set up 、 build 、 generate 、 compose 、 add 、 new 
  

• 用具体的名字代替抽象的名字

  在给变量，函数或者其他元素命名时，要把它描述的更具体而不是更抽象。

• 为名字附带更多信息

  一个变量名就像是一个小小的注释，有时候我们可以让它更有帮助些

• 附带其他的重要属性

• 名字应该有多长

  • 在小的作用域里可以使用短的名字
  • 首字母缩略词和缩写: doc = document
  • 丢掉没用的词
  • 利用名字的格式来传递含义

第三章——不会误解的名字

• 推荐使用 min 和 max 来表示（包含）极限
• 推荐使用 first 和 last 来表示包含的范围
• 推荐使用 begin 和 end 来表示包含/排除范围

第四章——审美

• 原则：
  • 使用一致的布局，让读者很快就习惯这种风格
  • 让相似的代码看上去相似
  • 把相关的代码行分组，形成代码块

第五章——该写怎样的注释

• 什么地方不需要这注释
• 应该记录下来一些想法：为什么代码写成这样而不是那样、TODO、常量为什么是这个值
• 站在读者的角度去思考：
  • 预料到那部分的代码会让人搞不清楚，加上注释
  • 为读者意料之外的行加上注释
  • 在文件/类的级别使用“全局观”注释来解释所有的部分如何一起工作的

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

• 避免使用不明确的代词
• 尽量精确描述函数的行为
• 精心挑选输入/输出的例子
• 声明代码的高层次意图，而非明显的细节
• 用嵌入注释解释难以理解的函数参数
• 用含义丰富的词语

第二部分——简化循环和逻辑

第七章——把控制流变得易读

• 条件语句中参数的顺序：左侧的值倾向于不断变化、右侧的值更倾向于常量
• if/else 语句块的顺序：首先处理正逻辑而不是负逻辑、先处理简单的情况
• ?: 表达式：只有在简单的情况下使用
• 避免 do/while 循环
• 最小化嵌套
• 从函数中提前返回

第八章——拆分超长表达式

• if line.split(':')[0].strip() == "root"改为username = line.split(':')[0].strip();if username == "root"
• 拆分巨大的语句

第九章——变量与可读性

变量越多，就越难全部跟踪他们的动向
变量的作用越到，就需要跟踪它的动向越久
变量改变的越频繁，就越难以跟踪它的当前值

• 减少变量，即那些妨碍的变量。通过离开处理结果来消除“中间结果”变量。
• 减少每个变量的作用域，越小越好。
• 只写一次的变量更好，那些只设置一次值的变量（或者 const 、final 、常量）使得代码更容易理解。

第三部分——重新组织代码

第十章——抽取不相关的子问题

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

应该把代码组织得一次只做一件事情。

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

学会用自然语言描述你要实现的功能，写出和描述匹配的代码。

第十三章——少写代码

• 从项目中消除不必要的功能，不要过度设计
• 重新考虑需求，解决版本最简单的问题
• 经常性地通读标准库的整个API，保持对它们的熟悉程度

第四部分——精选话题

第十四章——测试与可读性

• 使测试易于阅读和维护
• 让错误消息更具可读性
• 选择好的测试输入
• 简化输入值
• 为测试函数命名