代码整洁之道

第二章:做有意义的命名 —(2017-08-03日)

• 1.名副其实:选个好的命名,见名知意,变量,或函数,或类冯名称应该在看到名称就已经有了答案,如果名称需要注释来补充,那就不算是名副其实.
• 2.避免误导:避免留下和代码本意不符合的单词
• 3.做有意义的区分:有时候代码名称虽然不同,但是名称高含义确实相同的,这就导致程序员在看到命名时无法进行区别.
• 4.使用命名时,尽量使用我们能读出来的单词,避免与人交谈时产生单词读不出来的尴尬,书中说,编程本来就是一种社会活动
• 5.使用可搜索的名称:平常的单词名称和数字很难在代码中找出来,因为肯定会不引用.长命胜于短名称,但是如果短名称足够清楚,就要爱比长命称好,若变量或常亮可能在代码多处使用,应该给其的命名,便于搜索.
• 6.避免使用编码,避免使用前缀,在避必须使用编码的特殊情况时,在接口和实现命名时,尽量选择对实现进行编码命名.
• 7类名:类名和对象名应该是名词或者名词短语,类名不应该是动词.
• 8.方法名:方法名应该是动词或动词短语.
• 9:命名时做到言到意到,意到言到.
• 10.每个概念对应一个词,我们在写代码时,应当给每个抽象概念对应一个词,并且一以贯之.
• 11.尽量使用程序员熟悉的术语来命名,如果实在不能用术语命名,就采用所涉及领域名称来命名.

第三章:函数

3.1-3.7节(2017-08-04日)

• 1.函数就应该写的短小,函数应该二十行封顶.这样最佳.if 或者else或者while语句,其中的代码块应该只有一行,该行应该是一个函数调用.这样不但可以保持函数短小,还可以使用具有说明性的文字,使得代码更易于阅读和理解
• 2.只做一件事,函数应该做一件事,做好这件事,只做这一件事.判断函数是否不止做了一件事,就是看这个函数还能否拆分出一个函数.因为只做一件事的函数无法呗被合理的切分为多个区域.
• 3.函数中的语句都要在同一抽象层级上,自顶向下读代码,让每一个函数后面都跟着位于下一抽象层级 的函数.
• 4.用描述性的名称,当我们命名函数时,要让函数名较好的描述函数做的事.函数越短,功能越集中,就越便于取个好名字.不要害怕名字长,因为具有描述性的长名字要比令人费解的短名称好,也要比描述性的长注释好,选择描述性的名称能清理自己关于模块的设计思路,并帮改进之.而且命名方式应该保持一致.
• 5.函数的参数:最理想的函数时是没有参数的,其次时是一个参数,然后是两个参数,避免使用三个或者三个以上的参数,切记,不到万不得已的时候不要这样做.

3.8-3.15节(2017-08-05日)

• 6.给函数取个好名字,能较好的解释函数的意图,以及参数的顺序和意图,对于一元函数和参数,应当形成一种良好的动词/名词对应行式.
• 7.应避免使用输出参数,如果函数必须要修改某种状态,就修改所属对象的状态.
• 8.函数要么是在做一件什么事,要么是回答什么事,一般二者不可兼得,函数应该修改某对象的状态,或者是返回该对象的有关信息,两者不要都干,否则会导致混乱.
• 9.抽离try/catch代码块,将主体抽离出来形成函数.处理错误就是一件事,处理错误的函数也只能做一件事.
• 10.重复代码是软件中一切邪恶的根源,重复代码会增加代码的臃肿,而且会增多代码的错误率,许多原则与实践规则都是为控制与消除重复而创建.
• 11.没有人能从一开始就能写出规整的代码,所以在写代码时,先写出来,再根据书中的方法,打磨,分解函数,修改名称,消除重复

第四章:注释(2017-08-06日)

• 1.如果编程语言足够有表达能力,或许我们擅长于用这门需要来表达意图,那么就不需要注释了.
• 2.为什么不建议使用注释,因为代码总是在改变,在演化,但是注释却不能总是随之变动.
• 3.注释不能美化糟糕的代码,当你需要用注释来解释你糟糕的代码时,倒不如花点时间清洁清洁自己糟糕的代码.
• 4.很多时候,其实当我们来写代码时,只需要想上那么几秒钟,就能用代码解释自己的大部分意图,只需要描述一个与注释所言同一事物的函数即可.
• 5.什么是好的注释,法律信息的注释,例如有时候公司规范要求,编写与法律有关的注释.提供信息的注释.公共api中的javadoc
• 6.能用函数或变量时就别用注释.而且在括号后面编写注释时,会给我们编写短小代码和封装代码带来混乱.
• 7.归属和署名,因为源代码控制系统非常善于记住是谁在在何时添加了什么,所以没有必要用小小的标签名.
• 8.不要直接把代码注释掉,要么用,要么删掉,这样的代码别人看到会以为是重要的,不会删掉,这样越来越多注释代码积累会弄脏我们的代码.

第五章:格式(2017-08-08日)

• 1.我们应该选用一套管理代码格式的简单规则,贯彻这套规则,在团队中应该一致同意,采用一套简单的格式规则,所有成员都去遵从.
• 2.格式目的:代码格式很重要,代码格式不可忽略,必须严肃对待,代码格式关乎团队沟通,而沟通是专业开发者的头等大事.
• 3.写出来的代码要像报纸上的文章一样,名称应当简单且一目了然.名称本身应该足够告诉我们是否在正确的模块中.
• 4.在封包声明,导入声明,和每个函数之间,都有空白行隔开,这条极简单的规则,极大的影响了代码的视觉外观.每个空白行都是一条线索,标识出新的独立的概念.
• 5.而紧密相关的代码应该互相靠近,不应该被注释隔断代码间的联系.
• 6.关系密切的代码就应该相互靠近,但我们经常遇到存在于不同文件的概念,不到万不得已,应该尽可能的把有密切相关的函数放在相同的文件.
• 7.变量的声明.应该尽可能的靠近其使用的位置.实体变量,应该在类的顶部声明至少在java代码中应该这样.
• 8.相关函数,如果某个函数调用了别的函数,就应该将其放在一起,并且调用者在被调用者上面.这样就极大增加了模块的可读性.
• 9.空格字符,我们在赋值操作符周围加上空格字符,以此达到强调的目的.
• 10.团队规则,每个人都有自己的代码格式规则,但是在团队中,应当认同同一种风格,并且每个人都去采用这种风格.

第六章:对象和数据结构(2017-08-09日)

• 1.隐藏实现并非只是在变量之间放上一个函数层那么简单,隐藏实现关乎抽象,类并不是简单的取值器和赋值器,而是曝露抽象接口,以便用户无需了解数据的实现,就能操作数据本体.
• 2.对象把数据隐藏于抽象之后,曝露操作数据的函数.数据结构曝露其数据,没有提供有意义的函数.
• 3.过程式代码既使用数据结构的代码,难以添加新的数据结构,因为要修改所有的函数,而面向对象的代码难以添加新的函数,因为必须修改所有类.
• 4.得墨忒耳律:模块不应该了解它所操作对象的内部情形.
• 5.方法不应该调用由任何函数返回的对象的方法.这类方式的代码应该杜绝.
• 6.最精炼的数据结构,是一个只有公共变量,没有函数的类.这种数据结构有时被称为数据传递对象[DTD].
• 7.对象曝露行为,隐藏数据,便于添加新对象类型,而无需修改既有行为,同时也难以在既有对象中添加新行为.
• 8.数据结构曝露数据,没有明显的行为,便于向既有的数据结构添加新的行为,同时也难以向既有函数添加新数据结构.

第七章:错误处理(2017-08-11日)

• 1.遇到错误时,应该抛出一个异常,这样的调用代码会很整洁,其逻辑不会被错误代码弄乱.
• 2.先写try-catch-Finally语句,当我们执行try中的代码时,表明可以随时取消执行,并且在catch中继续.
• 3.给出异常发生的环境说明,每次抛出异常,都行该提供足够的环境说明,以便判断错误的来源和出处.
• 4.当我们在应用程序中定义异常类时,最重要的是考虑它们如何被捕获.
• 5.别返回null,因为当你返回null时基本上就是给自己添加工作量,给调用者添乱.如果你打算在方法中返回null,不如抛出异常,或者是返回特例对象.
• 6.不要传null值,除非是API要求null否则就不要给函数中传入null值.
• 7.我们在代码中应该将错误处理隔离看待,独立于主要的逻辑代码,这样就能写出强固而整洁的代码.也极大的提升了代码可维护性.

第八章:边界(2017-08-12日)

• 1.一般来说,第三方程序包和框架提供者追求普适性,而我们这样的使用者则要满足特定需求的接口即可,这>- 种张力会导致系统边界上出现问题.
• 2.学习性测试毫无成本,无论如何我们都要学习要使用的api而编写测试则是获取这些知识的容易而不会影响其他工作途径.
• 3.代码中的边界是将已知和未知分隔开的边界.在代码中总有许多地方是我们的知识未及之处.

第九章:单元测试(2017-08-14日)

• 1.TDD三定律：
  a.在编写不能通过的单元测试前，不可编写生产代码。
  b.只可编写刚好无法通过的单元测试，不能编译也不算通过。
  c.可编写刚好足以通过通过测试当前失败测试生产代码。
• 2.保持测试代码整洁,测试代码和生产代码一样重要。它需要被思考，被设计和被照料，它该像生产代码一样整洁。
• 3.如果测试不能保持整洁，你将会失去它们。没有了测试，你就会失去保证生产代码可扩展的一切要素。
• 4.测试代码应该要有可读性。应该和其他代码一样，明确，简洁，还有足够的表达力。
• 5.按照 构造-操作-检验 模式，可以清晰的将测试拆分为三个环节。第一个环节构造测试数据，第二环节操作数据，第三部分检验操作是否得到期望的结果。
• 6.整洁的代码还要遵循以下规则。快速，独立，可重复，足以验证，及时。

第十章：类（2017-08-16日）

• 1.类的组织：类中应该由一组变量列表开始，公共静态常量在前，私有静态变量在后，然后时私有实体变量，接着是公共变量。公共函数跟在变量列表之后。工具函数在公共函数之后。
• 2.类应该短小，但是类的大小不取决于代码行数，而取决于权责。
• 3.单一权责原则认为，类或模块应该由且只有一条加以修饰的理由。
• 4.系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因。并与少数其他类一起协同达到期望的系统行为。
• 5.保持函数和参数列表短小的策略，有时会导致为一组子集方法所用的实体变量数量增加。出现这种情况应该尝试将这些变量和方法拆分到两个或多个类中，让新的类更内聚。
• 6.保持内聚性就会得到许多短小的类。

第十一章：系统

待读。。