编写可读代码的艺术（阅读笔记）

编写可读代码的艺术（阅读笔记）

最近看完了《编写可读代码艺术》这本书，做了一点笔记，和大家分享。

表面层次的改进

把信息装到名字

• 选择专业的名字。避免泛泛的名字（好的名字应该描述变量的目的）。具体代替抽象。使用前缀或者后缀。丢掉没用的词。
• 名字长度？小作用域使用短的名字。如果是大作用域，名字就需要包含足够多的信息。

名字不要引起误解

• bool变量可以用is, has,can,should。
• 名字要符合使用者的期待。轻量级就要对应轻量级的期待。

审美

• 使用一致的布局。
• 让相似的代码看起来相似。
• 把相关的代码行分组，形成代码块。
• 其他：一致性的风格比正确的风格更重要。个人服习惯遵从团队习惯。

注释

• 不要为了注释而注释。不要写没有价值的注释。一个好的名字比注释更重要。
• 好的注释要言简意赅，要明确细致。

简化循环和逻辑

把控制流变得易读

拆分超长的表达式

• 把表达式拆分成易于表达的块

变量和可读性

• 减少变量。
• 减小每个变量的作用域， 越小越好。 把变量移到一个有最少代码可以看到它的地方。
• 只写一次的变量更好。因为操作一个变量的地方越多，越难确定它的当前值。

重新组织代码

抽取不相关的子问题

• 抽取出可重用的函数，这种函数并不关心其他函数如何使用它。
• 给程序增加小函数过多，也不好。
• 把一般代码和项目专有代码分开。建立一大组库 和辅助函数来解决一般问题，剩下的只是让你的 程序与众不同的核心部分。

重新组织代码，使得代码一次只做一件事

• 一部分变成单独的函数，一部分划分成层次分明的段落。

把想法编程代码

少写代码

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

测试和可读性

测试代码的可读性和非测试代码同样重要。

让错误信息更具体。

取一个好的测试函数名称。

测试驱动开发TDD，开发代码的时候想着便于测试，可以让代码质量更高。但是也不能过多的关注测试过头。