《代码整洁之道》总结和笔记

2019-08-16 09:42:32来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

《代码整洁之道》总结和笔记

前言

《代码整洁之道》在业内有很高的知名度,被诸多前辈推荐给后来者阅读。本书以循序渐进改造一个小程序的方式,演示了一个程序可能的各种设计(在代码层面)。手把手教你该怎么设计代码,为何要这样设计,这样设计的好处是什么。通过一周的阅读,总结了如下要点。

一 函数

所有的编程都是从HellWorld这个小函数开始的,学会设计函数非常重要

  1. 函数要。短才方便阅读、维护和设计。(每个人都经历过读不懂自己代码的尴尬)

  2. 函数只做一件事。依照单一职责原则设计函数。一个函数可以:流程控制,逻辑判断,改变变量状态,以及做运算,或者调用多个下一抽象级的函数。

  3. 函数分解成多个抽象层级设计,高层函数只调用下次层函数,呈树状图,层层封装。
  4. 函数不应该有标识参数(除了作为API的函数),这意味着函数有至少两种执行方式,违反了第2条原则。而且明显能拆成多个小函数。

  5. 函数参数越少越好有,多个参数应该封装成一个整体传入的。如果逻辑上不是一个整体,则函数肯定能被拆成多个小函数然后被分别调用。第4条标识参数可以封装进整体传入函数,而不是直接作为函数的参数

  6. 函数真的最好只做一件事,不要为了一时方便顺手加几行代码。如登录验证时,函数用来验证username和password,在验证之后顺便给用户初始化些其他东西。会导致这个函数在其他时候无法验证用户信息。

  7. 底层函数不应该改变参数状态,如果想改变某类的状态,就把该函数加入该类,让它自己调用函数。如:把改变类x的状态的函数调用addFooter(x),改为x.addFooter()。

  8. 函数不要返回错误码,这需要你有错误码的枚举类,并且违反了开放封闭原则(你需要加入新错误码来扩展新错误),直接抛出异常就好了。(可以通过继承父异常来扩展)。但是实际上错误码的应用不比异常少,而且异常也会导致代码的臃肿。

  9. 函数名称应该描述清楚函数作用,避免频繁去看文档,这对于短小的函数来说不难办到,如果很难命名可能需要思考函数是否有依照以上原则设计(你一个函数可能做了很多事情)。并且名称的命名应该不容易与其他函数名称形成混淆。如:add()在calculator中意思是加,而在List中就不应该用add表示插入集合了,应该用insert或append。简单来说就是一个概念对应一个词,并且始终如一。

二 格式

每个人都有自己的编码风格,书中总结了一些Java及其他语言的建议

  1. 好的格式应该由小且精的代码片段(函数)组成

  2. 封包代码,导包代码,成员变量,函数方法。都用空行隔开,形成分开的代码块

  3. 函数按调用顺序从上到下排列,类变量在顶端声明,方法变量在使用前声明

  4. 一行代码不超过100个,同一行的计算可以按先后顺序用空格隔开,如:
    100 * 732 / (2+3) * (5-1)
    小括号内的运算全都挤在了一起,其他运算都有空格隔开,很容易看出运算顺序
  5. 缩进代表了一种包含关系。Java没有强制要求,但是python就是用缩进表示包含。
  6. 说了这么多最后总结道:老大规定用啥格式就用啥格式

三 注释

其实注释写了后,看的最多的还是自己

  1. 好代码只需要少量注释,代码就能表达意图——回到之前的内容,这要求我们写小且精的函数。(但这不是你不写注释的理由)
  2. 好的注释应该是这样的。如:对抽象意图或者深远意义的解释(如我这个函数为啥用这个方法实现);阐述长且难读的函数(这种难读不是因为代码写得烂,而是业务逻辑复杂);警示一些关键重要的部分(这些部分一般是函数会改变某些数据实体);TODO注释提醒并告知未来要做的事;学着公共API的JAVADOC写就是好注释(虽然也有少数烂注释);
  3. 烂的注释往往是这样的。如:多余的注释(简单函数强行加上注释,读源码会比注释更快);误导的注释(注释本来就是错的,可能源自你更新了代码没更新注释——小函数特别可能出现这个问题);注释掉的代码(你为何不删了代码?);废话太多的注释(语文是体育老师教的)。

四 类

书中对于函数的设计其实和类的设计思想是类似的,所以类应该功能单一且小巧,越小耦合性越低,最后用门面模式组合起来向外提供API就好了

五 系统

系统整体结构的设计

  1. 把系统的整体构造和业务使用分开。不要让构造影响使用,也不要让程序的运行反过来影响构造。这也是Spring这么应用广泛的原因之一,Spring Core就是个类容器。
  2. 把业务逻辑和检查或日志方案分离,不然纠缠在一起的代码会很难看懂和修改。Spring AOP也解决了这个问题。

六 测试

测试不仅仅是测试小姐姐的事情

  1. 测试函数(方法)也应该短小(如果函数原本够小的话测试函数自然会小)
  2. 每个类最好都测试下,测试时间会比以后debug时间少。从底层函数一点点测上去,以后debug能迅速定位。
  3. 测试类应该保存下来,方便每次修改后进行测试

原文链接:https://www.cnblogs.com/taojinxuan/p/11128232.html
如有疑问请与原作者联系

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:spring事务的@Transactional使用事务不生效问题

下一篇:基于有限状态自动机的数据类型识别功能(1)