整洁代码
简单代码规则
- 能通过所有测试
- 没有重复代码
- 体现系统中的全部设计理念
- 包括尽量少的实体,比如类,方法
童子军军规
让营地比你来时更干净
如果每次签入时,代码都比签出时干净,那么代码就不会腐败。清理不一定要花多少功夫,也许只是改好一个变量名,拆分一个有点过长的函数,消除一点点的重复代码,清理一个嵌套if语句
有意义的命名
- 使用读得出来的名称
- 使用可搜索的名称
长名称优于短名称,搜得到的名称胜于用自造编码写就的名称` 3.避免使用编码 例如,不要在接口前面前面加上I.应使用ShapeFactory而不是IShapeFactory,在接口前面加上I是一种废话 4.命名要准确 专业的程序员了解:明确才是王道. 专业程序员善用其能,编写其他人能理解的代码. 5.类名和对象名应该是名词或者名词短语 6.一以贯之的命名,保持统一 如果同一堆代码里有Controller,有manager还有driver,就会令人困惑.应统一成Controller
函数
1.短小
函数的第一规则是要短小,第二条规则是还要更短小 2.只做一件事
函数应该做一件事.做好这件事.只做这件事.可通过"能否再拆出一个函数"来判断是否不止做了一件事 3.每个函数一个抽象层级 4.避免使用太多参数 5.Don't repeat youself(DRY原则)
得墨忒尔律(也称"最少了解原理")
著名的得墨忒尔定律认为,模块布衣柜了解它所操作对象的内部情形.
对象隐藏数据,暴露操作.这意味着对象不应通过存取器暴露其内部结构,因为这样更像是暴露而非隐藏起其内部结构
类C的方法f只应该调用以下对象的方法: 1.C 2.由f创建的对象 3.作为参数传递给f的对象 4.由C的实体变量持有的对象
方法不应该调用由任何函数返回的对象的方法. (只跟朋友说话,不与陌生人谈话)
火车失事代码(看起来就像是一列火车,不推荐)
final String outputDir=ctxt.getOptions().getScratchDir().getAbsolutePath();
应该写成
Options opts=ctxt.getOptions();
File scratchDir=opts.getScratchDir();
final String outputDir=scratchDir.getAbsolutePath();
错误处理
错误处理很重要,但如果它搞乱了代码逻辑,就是错误的做法.
使用异常而非返回码.
遇到错误时,最好抛出一个异常,这样调用代码会很整洁,其逻辑不会被错误处理搞乱.
别返回null值.
别传递null值.
单元测试
TDD3大定律
第一定律
在编写不能通过的单元测试前,不可编写生产代码
第二定律
只可编写刚好无法通过的单元测试,不能编译也算不通过
第三定律
只可编写刚好足以通过当前失败测试的生产代码
没有了测试,你就会失去保证生产代码可扩展的一切要素. 正是单元测试让你的代码可扩展,可维护,可复用.
整洁的测试
整洁的测试的三个要素: 可读性,可读性和可读性.
在单元测试中,可读性甚至比在生产代码中重要
测试代码拼接字符串,不一定非要用StringBuffer,可直接"A"+"B" 这就是双重标准.有些事你大概永远不会在生产环境中做,而在测试环境中却完全没有问题.
可使用Given-When-Then的模板来写单元测试.
单个断言是一个好准则,单个测试中的断言数量应该最小化.
每个测试一个概念.
更好一些的规则或许是每个测试函数中只测试一个概念. 我们不想要超长的测试函数,测试完这个又测试那个.
整洁的测试还遵循5条原则(FIRST原则)
1.快速(Fast)
测试应该够快.测试运行缓慢,你就不会想要频繁的运行它,就不能尽早地发现问题.
2.独立(Independent)
测试应该独立.某个测试不应为下一个测试设定条件.应该可以独立运行每个测试,以及以任何顺序运行测试
3.可重复(Repeatable)
4.自足验证(Self-Validating)
测试应该有布尔值输出.无论是通过或失败,你都不应该通过查看日志文件来确认测试是否通过.
5.及时(Timely)
测试应及时编写.单元测试应该在恰好使其通过的生产代码之前编写.
类
类的组织
类应该从一组变量列表开始
顺序:
1.公共静态变量
2.私有静态变量
3.私有实体变量
4.公共函数
5.公共函数调用的私有工具函数
我们喜欢把有某个公共函数调用的私有工具函数紧随在该公共函数后面.这符合自上而下的
封装
1.我们喜欢保持变量和工具函数的私有性,但并不执着于此 2.有时,测试的时候需要将变量或者函数改为protected.总之,测试说了算
然而,我们首先会想办法使之保持隐私.放松封装总是下策.
类应该短小.
类的第一条规则是类应该短小,第二条规则是还要更短小.
单一权责原则(SRP)
类或者模块应该有且只有一条加以修改的理由.
内聚
类应该只有少数实体变量.类中的每个方法都应该操作一个或者多个实体变量.如果一个类中的每个变量都被每个方法所使用,则该类具有最大的内聚性.
保持函数和参数列表短小的策略,有时会导致一组子集方法所使用的实体变量数量增加.出现这种情况,往往意味着要从一个大类中拆分出来.你应该尝试将这些变量和方法拆分到两个或者多个类中,让这些类更为内聚.
保持内聚性就会得到许多短小的类
