代码整洁之道－－读书笔记

代码整洁之道－－读书笔记

代码整洁之道这本书首先给出了代码整洁的重要性。同时在工作中，我们也深有体会，整洁的代码能够提高我们阅读代码和改动需求的效率。在这本书中也加深了我对整洁代码认识，我对整洁的代码的理解是代码是正确的，能够通过所有的测试，代码简洁，易于读懂，可复用，便于维护的。

在一些具体的细节体现上如下：
- 命名的规范
- 函数的使用规范
- 注释的规范
- 类的设计规范

命名的规范

规范的命名能够降低代码的模糊程度，能够体现代码的用途和含义，这样程序的可读性就会提高。现列举一些如下：名副其实 。“名副其实”所表达的是见名知义。变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你,它为什么会存在,它做什么事,应该怎么用。如果名称需要注释来补充,那就不算是名副其实了。 避免误导，在变量命名中，应该避免使用与本意相悖的词。例如，如果一个变量不是一个集合类型，最好不要用List作为变量名的后缀。在Objective-C 这用语言中，也用遵循这种规范，类型后缀名要和所表达的类型相一致，不一致时就会产生误导。做有意义的区分，不同的命名，其含义也应是不同的。如果不同的命名只是让编译器满意，但是对于程序员而言，其含义不能做区分，那也是糟糕的命名。例如：假设你有一个 Product 类。如果还有一个 ProductInfo 或 ProductData 类,那它们的名称虽然不同,意思却无明显区别。此外，对于类名和变量名应该尽量使用名词来描述，对于，方法名应该用动词或者动词性短语。

函数的使用规范

函数应该尽量短小。短小的函数易读，而且比较简洁，功能集中, 便于取个好名字。当然也会有一些特殊的情况，如初始化一个模型，这个模型中有多个属性。这样的初始化方法肯定会很长，但是不违反函数只做一件事的原则，所以我觉得也是可行的，但一般的方法应该尽量的短小。函数应该只做一件事。如果函数只是做了该函数名下同一抽象层上的步骤, 则函数只做了一件事, 编写函数毕竟是为了把大一些的代码拆分为另一抽象层上的一系列步骤。要判断函数是否不止做了一件事, 还有一个办法,就是看是否能再拆出一个函数, 该函数不仅只是单纯地重新诠释其实现。要确保函数只做一件事, 函数中的语句就要在同一抽象层级上。向下规则。通常的阅读习惯是自顶向下的阅读顺序。我们想要让每个函数后面都跟着位于下一抽象层级的函数,这样一来,在查看函数列表时,就能顺着抽象层级向下阅读了。函数参数 。最理想的参数数量是零个,其次是一个,再次是二个,应尽量避免三个。有足够特殊的理由才能用三个以上参数。如果函数看起来需要两个, 三个或三个以上的参数, 就说明其中一些参数应该封装为类了，将对象作为参数进行传递。。

注释的规范

注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。书中提及关于注释的思想是最好的注释是代码本身，也既是代码的表达能够传达出完整的意思。如果代码暂时不能表达出很准确的意思，再考虑用注释来对代码的表达进行增强。

类的设计规范

对于类的组织应该遵循自顶向下原则。先是变量列表（公共先于私有，静态先于实体）然后是方法列表（工具方法紧跟在所属方法之后）然后对于一个类的设计应该保证其封装性，尽量不要将不必要的东西暴露给外界使用。其次类的设计应该短小：类名越明确，类的职责就越清晰。每个类单一权责，只有一个修改它的原因，并与少量的其他类协同完成工作；内聚：对于内聚的设计，类中含有较少的变量，保持高内聚；隔离修改：具体类负责实现细节，抽象类只呈现出一种概念，利用接口和抽象类可以隔离因为细节的改变而带来改变类的风险。

《整洁代码之道》这本书介绍的规范包含这些内容，但不仅限于这些内容。所以可以更深入的去研读这本书，体会《整洁代码之道》这本书中的关于代码整洁的思想。后续有新的体会，将继续跟进。