《代码整洁之道》读书笔记

Posted 默辨

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了《代码整洁之道》读书笔记相关的知识,希望对你有一定的参考价值。

文章目录

前言:
我们总说书上写的是死的,但人是活的,不要死读书。但在我看来,灵活使用的前提是你的知识储备已经具备了灵活掌握的程度,断然不是遇到别人引用书中的话语,并且这是一个我们没见过,且与我们认知有些违背,我们就说别人是死读书。这句话像极了对别人掌握知识的蔑视,我们都应该清楚的认识到,事物发展都需要过程。这一切的一切得结合时代、结合双方的认知程度等众多因素才能做出结论,不过当下我认为最好的状态,还是只对过程进行阐述,不下结论,《代码整洁之道》书中的观点亦是如此。

一、感悟

说实话这本书读起来没有太多的让我惊喜的时刻, 一方面可能是因为和《重构》有重叠,导致很多东西都比较熟悉,另一方面是书虽然接近400页,但是真正和书名高度相关的内容也就1/3;中间1/3的内容(测试、AOP、并发)在今天看来也有些太大众化,且由于相关技术点的实效性,自己仅做浅尝;最后还有接近1/3的附录代码,这部分直接白给。最后的结果就是,这本书读起来没有拿在手里感觉的那么厚。


同样的,对书中一些比较有感觉的点进行记录:

部分感悟和《重构:改善既有代码的设计》这本书有些重叠的,无妨,多重复几遍,有些东西就能体会的更加深刻。

1、命名单词的选择上尽可能的基于一个大的底座,类名:名词或名词短语;方法名:动词或动词短语;
2、在一些常量的魔法值的处理上,要使用具有业务含义的命名,并且命名具有辨识度,这样有助于未来的定位相关魔法值;
3、方法的业务逻辑需要保持在同一个抽象层级上,并且最终方法构建的形态是一课平衡树,拒绝业务含义上的头重脚轻;
4、方法不要出现副作用,做了什么事情,回答了什么事情要能够独立区分
5、注释应该有其确定的作用,而不是为了解释而强行添加,过多的注视只会影响观感
6、单纯的DTO数据对象,不要含有业务逻辑方法
7、遵从迪米特法则,方法不应该调用任何方法返回的对象的方法,除非这个方法返回的对象是一个数据结构,而非对象结构
8、抛出的错误应该要能清晰的定位错误的来源和位置
9、方法尽量不要返回null和传入null
10、不要依赖直觉去判定代码的正确性,应该探索边界,并且编写对应的测试
11、不要让父类依赖子类
12、如果想让多个函数呈现出一定的顺序,可以在方法的如参上进行限定,继而保证方法的顺序
13、函数的名称应该代表其具备的行为
14、配置相关的参数,应该在较高的抽象层级上进行获取,然后以参数的形式进行传递




二、脑图

代码整洁之道读书笔记

代码整洁之道

 

前言 代码整洁之道

如何用功

  阅读大量代码

  找优点和缺点

第一章 整洁代码

不要留到以后,稍后等于永不

烂代码影响生产力

代码整洁性不但有关效率,还有关生存

好代码

  C++之父

   尽量减少依赖关系,便于维护

   性能调至最优,防止修改导致混乱

   分层战略完善错误处理代码

   代码逻辑直接了当 叫缺陷难以隐藏

  破窗理论

   破损的窗户开辟了大厦走向颓废的道路

  只包含必须之物,果断决绝

  TDD 有单元测试,验收测试,少的依赖关系,少的API

  越小越好

  少的代码重复

童子军军规

  让营地比你来时更干净

第二章 有意义的命名

名副其实

  不要有魔数数

避免误导

  最好不用List的容器名字如accountList

  避免使用不同之处较小的名称

  避免使用 O o 0 l 1这种字

做有意义的区分

使用读得出来的名称

使用可搜索的名称

避免使用编码

  不要使用 IShapeFactory 不对接口编码

  对实现编码 如ShapeFactoryImpl

避免思维映射

  不应当让读者在脑中把你的名称翻译为他们熟知的名称

  明确是王道

类名

  是名词或名词短语

  避免使用Manager Processor Data Info 类名

  重载构造器时,使用描述了参数的静态工厂方法名

每个概念一个词 get fetch

避免双关语 一词多义

第三章 函数

短小

  函数不该长于一屏幕

  20行封顶最佳

  if elese while 语句 代码块应该只有一行

只做一件事

  判断是否做了一件事,就看能否在拆出一个 函数,该函数不仅只是单纯地重新诠释其实现

  如果一个函数只是做了该函数名下同一抽象层的步骤,则还是租了一件事

每个函数一个抽象层级

使用描述性的文字

  命名方式保持一致

   讲出一个故事

抽象工厂代替switch语句

函数参数

  最理想是零参数

  尽量避免三参数,有足够理由才能超过三

  尽量使用返回值,而不是输出参数 如 void transStringBuffer out)和 StringBuffer trans(StringBuffer in)后者好

  不应该使用表示参数,如 render(true) 应该使用两个独立的函数替换

  二元函数要付出代价,可以通过成员变量,抽象出新类来避免

  多个参数,应该考虑参数对象

  不能有副作用

   不能产生其他潜在操作

  分隔指令与询问

   要么做什么事,要么回答什么事,不能兼得

使用异常替代返回错误码

  错误处理代码从主代码路径中分离出来

不要重复自己

如何写函数

  先写,打磨,分解,修改名称,消除重复

第四章 注释

注释恰当用法是弥补在用代码表达意图时遭遇的失败

花时间清洁代码,比写注释要好

很多时候,简单到秩序创建于注释描述一致的函数

好注释

  法律信息

  提供信息的注释

  对意图的解释

  警示

   大型操作

   一般使用 @Ignore 关闭测试用例

坏注释

  喃喃自语

  多余的注释

  误导性的注释

  循规式的注释

  日志式注释

  废话注释

  能用函数活变量就别用注释

  括号后的注释

   如 } // try 等

   应当缩短函数,重构代码

  归属与署名

   应该依赖于源代码控制系统

  注释掉的代码

第五章 格式

格式的目的

  代码可读性影响到可维护性和扩展性

垂直格式

  短文件比长文件易于理解

  向报纸学习 有大纲 由浅入深 不长

  每组代码有一个空格,层次感

  垂直方向上区隔的作用

  垂直方向上的靠近

   紧密相关的代码要靠近,而不能用注释隔开了

  垂直距离

   本地变量应该靠近其使用位置,在函数顶部

   实体变量应该在类的顶部声明

   相关函数

    某函数调用另一个函数,应该放在一起

    调用者在被调用者上面

   概念的函数应该放在一起,如重载的函数

   垂直顺序

    自上而下展示函数调用依赖顺序

横向格式

  代码行上限应该是120个字符

  尽量不要拖动滚动条

  水平方向的区隔与靠近

   赋值操作符周围加上空格字符,达到强调的目的

   函数名和左括号不加空格,紧密相关

   括号中的参数一一隔开,强调逗号

  水平对其

   修饰符、参数类型,参数名起头在同一纵向上

团队规划

  格式规则团队说了算

  同一规则,借助IDE

最优代码格式

  成员变量声明应该紧紧挨着

  与构造器应该有一定间隔

  方法调用由上而下

  结构紧凑

  方法之间有间隔

  while for if 只有一句的时候,不要用 {}

第六章 对象和数据结构

数据抽象

  使用接口,不暴露细节,即使get set 方法,也可能暴露接口

  以最好的方式呈现某个对象包含的数据

数据对象的反对称型

  对象把数据隐藏于抽象

  数据结构暴露其数据

  过程式代码与面向对象代码

   过程式代码难以添加新数据结构,因为必须修改所有函数

   面向对象代码难以添加新函数,因为必须修改所有类

德墨忒尔定律

  模块不应了解它所操作对象的内部清醒

  隐藏内部结构

  类C 方法f只应该调用一下对象方法

   C

   f创建的对象

   作为参数传递给f的对象

   C的实体变量持有的对象

  隐藏结构 知道的尽量少

数据传送对象

DTO 数据传送对象

  只有公有变量,没有函数

第七章 错误处理

错误处理不能搞乱了逻辑代码

遇到错误的时候,最好抛出一个异常

try-catch-finally

  定义了一个范围

  try部分可随时取消,在catch语句接续

可控异常违反开闭原则

  抛出异常后必须修改调用者的方法签名 生命异常

  破坏封装

给出异常发生的环境说明

  失败操作

  失败类型

打包第三方API

  降低对他的依赖

  不用很痛苦的改代码库

  方便mock和模拟

  尽量封装自己的异常

不要返回null值

  返回特例对象

  可以返回空列表 Collections.emptyList()

不要传递null值

  除非API要求 否则尽量不传null值

第八章 边界

整洁的边界

  边界代码需要清洗分割和定义期望的测试

  避免过多了解第三方的特定信息

第九章 单元测试

编写测试,确保代码中每个犄角旮旯都如我所愿的工作

隔离 伪造

TDD三定律

  先写测试 后写代码

  1.在编写不能通过的单元测试前,不可写生产代码

  2.只可以编写刚好无法通过的单元测试,不能编译也算不通过

  只可以编写刚好足以通过当前失败测试的生产代码

测试代码和生产代码一样重要

保持测试整洁

没有单元测试,生产代码无法扩展,不敢修改

整洁的测试

  整洁测试三要素

   可读性

   可读性

   可读性

  明确、简洁,有足够的表达力

  测试的三个环节

   构造测试数据

   操作测试数据

   验证操作是否得到了期望的结果

  断言数量最小化

   尽量一个测试一个断言

  每个测试一个概念

整洁测试的五条规则 F.I.R.S.T

  快速 fast

   快速运行

  独立 independent

  可重复 repeatable

   任何环境下可重复通过

  自足验证 self-validating

   应该有布尔值输出

  及时 timely

   应该及时编写

以上是关于《代码整洁之道》读书笔记的主要内容,如果未能解决你的问题,请参考以下文章

代码整洁之道读书笔记(Ch4-Ch7)

《代码整洁之道》读书笔记

代码整洁之道 读书笔记

代码整洁之道 读书笔记

第九次读书笔记——读《代码整洁之道》有感

《代码整洁之道》读书笔记-1