读书笔记--代码整洁之道--其二

第三章 函数

 

1.函数的第一规则是要短小，第二条规则是还要更短小。

2.函数应该做一件事。做好这件事。只做这一件事。

3.尽量少的函数参数。有两个参数的函数要比一元函数的难懂。如果需要三个或者三个以上的参数应该封装成类了。

4.不要重复自己。

PS:如果一段相同的代码出现了两次，你是不是觉得自己改做些什么了。

 

第四章 注释

 

注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。作者认为注释是一种失败，我们总无法找到不用注释就能表达自我的方法，所以总要有注释，这并不值得庆贺。写注释的常见动机之一是糟糕代码的存在。带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎而复杂的代码像样的多。与其花时间编写解释你搞出的糟糕的代码注释，不如花时间清洁那堆糟糕的代码。

PS:这段话看起来可能有些过激。我们确实可以通过好的编码习惯减少不必要的注释。不过现在自动生成文档的技术都是从代码的注释中提取的。如果是这种情况，上司肯定是要求你写完备的注释的。

 

好注释：

 1. 法律信息。有时，公司代码规范要求编写与法律有关的注释。例如版权和著作申明。

 2.提供信息的注释。   

// returen an instance of the Responder being tested
protected abstract Responder responderInstance();

 不过作者认为 将函数名 重新命名为 responderBeingTested 注释就是多余的。

 3.对意图的解释。 有时注释不仅提供了有关实现的有用信息，而且还提供了某个决定后面的意图。

 4.阐释。 有时注释把某种晦涩难明的参数或返回值的意义翻译为某种可读形式。也会是有用的。特别是参数或者返回值是某个标准库的一部分，或者你不能修改代码，那帮助阐释其含义的代码就会有用，例如:

assertTrue(bb.compareTo(ba)==1);//bb>aa
assertTrue(a.compareTo(b)==-1);//a<b

直接看方法可能不明确，但有注释就明白多了。我看这2,3,4都是一个意思。就是说明是干嘛的。

5.警示，告诉别人要注意这个方法之类的。

6.放大。有的代码可能看着有点多余，但编码者当时是有他自己的考虑，这个时候需要注释下这个代码的重要性。避免后面被优化掉。

第五章 格式

纵向格式：

1. 函数与函数之间留空行。

2.变量声明：变量声明应该尽可能靠近其使用位置。因为函数很短，本地变量应该在函数的顶部出现。

3.实体变量 应该在内的顶部，相当于我们的field 字段，会被使用的多。

4.相关函数，如果某个函数调用另外一个，就应该把他们放在一起，而且调用者应该尽可能放在被调用者的上面。这样这个程序就会自然有序。（之前我喜欢把private的方法 放到一起。当然这确实没有什么实际的意义）

5.“相关概念的代码放在一起。相关性越强，比如一个大功能逻辑靠在一起。” （更多的时候我喜欢用 region 来收起来。）

 横向格式：

1.一行的长度，作者建议是上限是120个字符

PS 平时我们都是按照自己的屏幕大小来决定，当然太长了，自己也不便阅读，又不是压缩的js文件

2.赋值语句两端留空。

a = b ; 

3.不在函数名和左括号间加空格。因为函数与其参数密切相关。

4.缩进。源文件是一种继承结构，而不是一种大纲结构，继承结构中的每一层级都圈出一个范围， 也就是代码块，其中有声明语句和执行语句。要体现这种继承结构，就要对源代码进行缩进处理。但有时候我们会把if语句，while循环，或小函数写成一行，但这样没有层级的概念，不便阅读，还是缩进的好。

第六章 对象和数据结构

1.过程式代码（函数编程）便于在不改动既有数据结构的前提下添加新函数，面向对象代码便于在不改动既有函数的前提下添加新类。反过来讲也说的通,过程式代码难以添加新的数据结构，因为必须修改所有函数，面向对象代码难以添加新函数，因为必须修改所有类。所以在设计的时候要分析好是以后是要添加新函数还是要添加新的数据结构。

2.德墨忒尔律：模块不应该了解它所操作对象内部情形。比如C的方法f只能调用以下对象的方法。

• C
• 由f创建的对象
• 作为参数传递给f的对象
• C的实体变量持有的变量

var outpath=cxt.getOptions().getScart().getAbsolutePath();

这个代码就违反了上面的德墨忒尔律，调用了返回值的方法。这样就是暴露了内部结构。