CleanCode-读书笔记

CleanCode读书笔记

最小惊异原则

1.从一而终,便于修改

2.遵守大家的约定

有意义的命名

1.名副其实


1.命名需要注释来补充,那就不算名副其实

2.在命名时尽量采用有意义的名称,代码的简洁不会改变(运算符和常量的数量,嵌套数量)

2.避免误导


1.避免使用与本意相驳的词

2.提防使用不同之处较小的词

3.不要使用小写l和大写O作为变量名

4.命名有区分,应当有明显的区分,应使读者可以鉴别

3.使用读得出来的名称

4.使用可搜索的名称


1.长名称胜于短名称,搜得到的名称胜于自造的名称

2.单字母仅用于短方法中的本地变量

3.名称长短应与其作用域大小相对应

4.若变量或常量可能在代码中多次使用,则应赋予其便于搜索的名称

5.避免使用编码和前缀

6.避免思维映射


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

7.类名和方法名


1.类名和对象名应该是名词

2.类名不应是动词

3.方法名应当是动词或动词短语

4.属性访问器,修改器和断言应该根据其值命名

8.宁可明确,勿为好玩

9.每个概念对应一个词

10.避免将同一单词用于不同目的

11.使用解决方案领域名称

12.使用源自所涉问题领域的名称

13.添加有意义的语境

2.函数

1.短小


1.if,else,while 语句,其中的代码块应该只有一行

并且应该大抵是一个函数调用语句

2.函数不应该大到足以容纳嵌套语句

3.永不调用的函数应该丢弃

2.只做一件事


要判断函数是否不止做了一件事,就是看能否再拆出一个函数

3.使用描述性的名称


1.函数越短小,功能越集中,就便于取个好名字

2.长而具有描述性的名称要比短的名称或者注释好

4.函数参数应少,并且不要使用输出参数


1.如果函数需要很多参数,说明需要封装为类

2.函数名称为动词可以明确函数是做什么的

3.函数参数自然而然的视为输入参数

4.将代码集中到基类i,避免冗余和重复

3.注释

1.注释不能美化糟糕的代码

2.注释的内容


1.版权及著作权声明

2.提供基本信息

3.对意图解释(提供某个决定的意图)

4.阐释(如果参数或者返回值是某个标准库的一部分,或者不能修改,帮助其阐释含义)

5.警告其他程序员会出现某种后果

6.//TODO注释(放置工作列表:程序员认为应该做,但由于某些原因还没有做的工作)

7.不要留下注释代码

格式

1.纵向格式


1.封包声明,导入声明,每个函数之间,用空白行隔开

2.关系密切或概念相关的代码应该互相靠近

3.变量声明应尽可能的靠近使用位置

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

5.循环中的控制变量应该在循环语中声明

6.相关函数(相互靠近,调用者应该在被调用者的上面)

2.横向格式


1.赋值操作符周围加空格

2.函数名和左圆括号不能分开(函数于其参数关系紧密)

3.根据运算符优先级在运算部分加空格

4.if,whle,短函数 不要违反或忽视缩进

5.while,for 语句的语句体为空,应该把语句体分号换行缩进

对象和数据结构

1.数据对象的反对称性


1.过程式(使用数据结构)代码便于在添加新函数

2.面向对象代码难以添加新类

2.Demeter律


1.模块不应了解他所操作对象内部的情况

3.DTO


1.数据传送对象,只有一个公共变量,没有函数的类

2.使用于数据库通信,解析套接字传递

错误和异常处理


1.给出异常发生的环境说明

2.依调用者需要定义异常类

3.不能返回和传递NULL值

类应该短小

启发

一般性问题


1.一个源文件不要使用多种语言(尽力)

2.明显的行为未被实现,阅读者不会再相信编写者

3.尽可能找到并且删除重复

4.基类不能依赖于派生类

5.不执行的代码应该删除

java


1.通过使用通配符避免过长的导入清单

2.不要继承常量

3.多使用enum而非常量

单元测试及JUnit以后再读一遍


1.测试不充分

2.使用覆盖率工具(容易发现测试不足的模块)

3.别略过过小的测试

4.特别注意测试边界条件

5.缺陷趋于扎堆,全面测试相近的部分

6.测试应该快速

CC BY-NC 4.0

Git学习笔记

Comments