第三章 函数
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.放大。有的代码可能看着有点多余，但编码者当时是有他自己的考虑，这个时候需要注释下这个代码的重要性。避免后面被优化掉。
链接：https://www.cnblogs.com/stoneniqiu/p/4815259.html?utm_medium=referral
以前自己的做法：以前自己没有想到函数的简化，总是想把一个功能作为一个函数，不管复杂不复杂，也有很多地方一直重复了，相同的部分有很多，因为对调用不太熟练，注释一方面不是很重视
现在应该如何做：函数记得简便，记得把相同的地方，构造一个函数，简化代码量，对于复杂的代码应该加注释 防止下次看的时候i忘记