​​最近看了《编写可读代码的艺术》收获颇丰，刚好这本书的读书笔记适合放在这里。程序员的一大乐趣就是可以自己决定创作出的东西，而代码的可读性、代码是否优雅，都决定了你作品的好坏，想要好的作品吗？那就想办法写出更优美的代码吧。

目录

前言

第1章 代码应该易于理解

第一部分 表面层次的改进

第2章 把信息装到名字里

第3章 不会误解的名字

第4章 审美

第5章 该写什么样的注释

第6章 写出言简意赅的注释

第二部分 简化循环和逻辑

第7章 把控制流变得易读

第8章 拆分超长的表达式

第9章 变量与可读性

第三部分 重新组织代码

第10章 抽取不相关的子问题

第11章 一次只做一件事

第12章 把想法变成代码

第13章 少写代码

第四部分 精选话题

第14章 测试与可读性

第15章 设计并改进“分钟/小时计数器”

前言

程序员之间的互相尊重和对工作的尊重都体现在代码中。

代码是写给人读的，应该便于理解，优质的代码可以让协作变得高效。

学习编写好代码的习惯，并应用于实践中。

第1章 代码应该易于理解

• 代码的写法应该使别人理解它所需的时间最小化。
• 要多想一想当前在写的代码别人是否容易理解它。

第一部分 表面层次的改进

• 代码风格
• 命名
• 排版
• 注释

第2章 把信息装到名字里

• 选择专业的词。
• 避免泛泛的名字。
• 用具体的名字代替抽象的名字。
• 使用前缀或者后缀附加更多信息。
  • 增加单位。如time_cost_day, time_cost_ms
  • 当前数据格式。如i_days，f_days。
  • 未处理的变量前面加raw_等
• 控制名字长度的依据
  • 如果变量作用域小，则可以使用较短的名字。如果变量作用域较大，则尽量使用信息完备的名字。
  • 采用缩写的原则是：团队新成员能否理解这个命名
• 利用名字的格式来表达含义
  • 可参考Google C++代码风格
  • 类名、函数名首单词大写
  • 宏全大写
  • 变量名全小写，用下划线隔开
  • 成员变量最后可以加下划线等，如CountChars_
• 如果一个flag要用于多个模式选择，那么就拆分flag，给他们不同的命名。

第3章 不会误解的名字

• 多问自己几遍，这个名字会被别人解读为其他含义吗？
• 命名尽量具体
• 用min、max表示包含的极限
• 用first和last表示闭区间（stop表示右开，last是右闭）
• 用begin和end表示左闭右开区间
• 给布尔值命名
  • bool read_password = true，不能确定是需要读密码还是已经读取了密码
  • bool need_password = true会更好。
  • 通常加上is、has、can、should这样的词可以让布尔值更加明确。
• 命名需要与使用者的期望相匹配
  • 如GetMean（），可能是直接获取已经计算好的mean，也可能是循环计算mean。改成ComputeMean会更好。
  • 如调用size（）可以改为CountSize（）。

第4章 审美

• 保持自己风格一致
• 让相似的代码看上去相似
• 把相关的代码行分组，形成代码块
• 列对齐：整洁易读，容易发现错误。
• 选择一个有意义的顺序，始终一致的使用它。如：
  • 从最重要，到最不重要排序。
  • 按字母顺序排序
• 用空行把代码分成逻辑上的段落
  • 相似的想法放在一起并且与其他想法分开
  • 提供可见的注释脚印
  • 便于段落间导航
• 保持风格一致性（一致的风格比正确的风格更重要）

第5章 该写什么样的注释

• 注释的目的是尽量帮助读者了解的和作者一样多。
• 什么情况下不需要注释
  • 不要为那些通过代码本身就能快速推断的信息做注释。
  • 一个好的名字比好的注释重要，不要给不好的名字加注释，应该把名字改好。
  • 好代码 > 坏代码+好注释
• 用代码记录你的思想
  • 加入导演评论。记录自己的思考。
  • 为代码中的瑕疵写注释。
    • 增加TODO，FIXME，HACK等
• 站在读者的角度，去想象他们需要什么

第6章 写出言简意赅的注释

• 注释应该有很高的（信息/空间）利用率
• 让注释保持紧凑，要保持注释的简洁
• 避免使用不明确的代词
• 润色粗糙的句子。
• 精确的描述函数的行为
• 用输入、输出的示例来说明特别的情况。
• 声明代码的意图。有时候这种注释扮演了冗余检查的角色。
• 对于不好理解的实参，标明形参名。
• 采用信息含量高的词。
  • 有些普遍的问题和解决方案会重复出现。通常会有专门的词或者短语代指这些场景、模式。建议采用这些值。

第二部分 简化循环和逻辑

• 控制流
• 逻辑表达式

第7章 把控制流变得易读

• 把条件、循环以及其他对控制流的改变做的越符合直觉越好。让读者不用反复的去看一段代码。
• 条件语句中参数顺序的选择
  • 会变化的值放在比较的左侧，常量值放在比较的右侧。 
    • if ( length > 10) 比 if ( 10 <= length ) 更符合直觉
    • while ( bytes_received < bytes_excepted ) 比 while ( bytes_excepted > bytes_received ) 更符合直觉。
    • 这种做法符合我们的思维习惯：“如果你的年龄不小于18岁”，“如果18岁大于等于你的年龄”。
• if else 语句块的顺序，先判断哪种情况？
  • 首先处理正逻辑的情况，如 if (debug) 而不是 if(!debug)
  • 先处理掉简单的情况。
  • 先处理特例或者复杂情况。
• ? : 条件表达式的使用场景
  • 如果想使用三目运算符来减少代码行数，需要判断采用三目运算符是否会导致读者理解它的成本增加。
  • 建议：默认情况都用 if else，三目运算符只在最简单的情况下使用。
• 在一个函数中，不同情况可以有不同的return语句
• 不要用go/to
• 不要用do/while
• 最小化花括号嵌套
  • 嵌套出现的原因：对于写代码的人来说，他是从已有的条件里面找到了一个适合增加新嵌套的地方，对他来说很好理解和直观。但是对于看代码的人来说，复杂的嵌套是一个整体，思维需要频繁出入栈，不易理解。
  • 避免嵌套：每次增加嵌套都从一个全新的角度来审视，不要基于自己已有的理解。
  • 通过提前return尽快离开嵌套。
• 减少控制流使用的次数
  • 如线程、中断处理、异常、函数指针和匿名函数、虚方法。过多的采用会导致控制流难以理解，尽量将这些操作隔离开。

第8章 拆分超长的表达式

• 把超长的表达式拆分成容易理解的小块。
• 增加一个用于解释中间值的变量。
• 容易理解的表达式，如果需要反复出现，也可以用变量代替。
• 利用德摩根定理将判断语句等价转换，有时候可以增加可读性。
• 将短路逻辑改的直观
  • 短路逻辑即：( if a == True || b == True ); 如果a == True为真，则 b == True不会执行 
  • 如 assert ( ( !( bucket = FindBucket(key) )) || !bucket -> IsOccupied() );
  • 可以改为
    • bucket = FindBucket(key);
    • if (bucket != Null) assert ( !bucket -> IsOccupied() );
  • 以直观为主，有时候短路逻辑反而更直观，如从a, b, c中找出第一个为真的值
    • x = a || b || c
• 反向思考，对于长判断表达式是否有更优雅的、判断它的反情况的方式。

第9章 变量与可读性

• 减少变量个数
  • 减少没有价值的临时变量。
  • 减少用于保存中间结果的变量。
  • 减少用于控制流的变量。
• 缩小变量的作用域
  • 避免使用全局变量。 
  • 让你的变量尽量对少的代码行可见。
  • 尽量使用静态方法。
  • 把变量的定义移动到使用它之前，不要在文件开始去定义所有变量。
  • 在C++中多使用const，在Java中多使用final。这样读者就不用思考这个变量的改动。
  • 操作一个变量的地方越多，越难确定它的当前值。

第三部分 重新组织代码

• 组织函数。
• 抽取出那些与程序主要目的不相关的子问题。
• 重新组织代码使其一次只做一件事情。
• 先用自然语言描述代码，然后用这个描述来找到更简洁的解决方案。

第10章 抽取不相关的子问题

• 工程学就是把大问题拆分成小问题，再把这些小问题的解决方案放到一起。
• 如果有一些代码在当前函数中正在解决与当前函数无关的子问题，那么就单独抽出来实现一个函数。
• 不相关的子问题完全是自包含的，不用关心其他人怎么调用它。
• 如果你希望有一个工具来解决现在的某个问题，那就去实现它。
• 将代码模块化。
• 创建大量通用式代码，自成一库。
• 简化接口。
• 过犹不及，不要过分拆函数，以可读性为主。

第11章 一次只做一件事

• 将初始化对象、处理输入、逻辑等相互分开。
• 一个代码块一次只做一件事，也可以根据需要将其拆分成不同函数。
• 任务可以分的很细。

第12章 把想法变成代码

• 如果你不能让一个完全没有基础的人把你所做的事情听明白，那么你就没有真正理解这件事。
• 代码就是你想法的实现，读者需要从你的实现中理解你的代码
  • 像对着同事一样用自然语言描述代码要做什么。
  • 注意描述中所用的关键词和短语。
  • 写出与描述相匹配的代码。
• 清楚地描述逻辑。
• 了解你所用的函数库。

第13章 少写代码

• 最好读的代码就是没有代码。
• 功能越简洁越好。
• 质疑和拆分你的需求，它真的需要这个功能吗？
  • 减少需求。
  • 解决更简单的问题。
• 代码库越小、越轻量越好。
  • 创建越多越好的工具代码来减少重复代码。
  • 减少无用代码或者无用功能。
  • 让项目保持独立的子项目状态。
• 熟悉你所使用的库，很多你需要的功能它们已经实现了。
  • 每隔一段时间，花15分钟阅读标准库中的所有函数、模块、类型名。并不是为了记住，而是需要的时候有个印象，知道无需自己实现。
• 代码越多就越难维护。
• 不要过度设计。

第四部分 精选话题

• 作者精选出的两个应用示例。

第14章 测试与可读性

• 对使用者隐去不重要的细节，以便更重要的细节更加突出。
• 让打印信息具有可读性。
• 了解常用的一些库。如python中的unittest。

第15章 设计并改进“分钟/小时计数器”

• 一个更加具体的案例。

博主会持续更新一些深度学习相关的基础知识以及工作中遇到的问题和感悟，喜欢请关注、点赞、收藏。

最后

以上就是复杂春天为你收集整理的【日常积累 - 04】《编写可读代码的艺术》- 写出优雅的代码前言第1章 代码应该易于理解第一部分 表面层次的改进第二部分 简化循环和逻辑第三部分 重新组织代码第四部分 精选话题的全部内容，希望文章能够帮你解决【日常积累 - 04】《编写可读代码的艺术》- 写出优雅的代码前言第1章 代码应该易于理解第一部分 表面层次的改进第二部分 简化循环和逻辑第三部分 重新组织代码第四部分 精选话题所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。