书籍:代码整洁之道
@StartTime:2018年08月19日11:57:14
@ReadHistory:
1. 2018年08月19日11:57:25
2. 2018年08月26日19:28:32
第一章:整洁代码
- 写整洁代码方法
- 减少重复代码
- 提高表达力
- 提早构建简单抽象
第二章 有意义的命名
- 名副其实
变量、函数或类的名称应该已经答复了所有的问题,它应该告诉你,它为什么会存在,它做什么事,应该怎么用。如果名称需要注释来补充,那就不算是名副其实。
避免魔法值 if(“XXX”==YYY)—>if(name.isValid())
- 避免误导
避免使用与本意相悖的词。
eg:accoutList如果不是list类型,则用accountGroup或accounts更好。
- 做有意义的区分
要区分名称 就要以读者能鉴别不同之处的方式来区分。废话都是荣誉。Variable一词永远不应当出现在变量名中;table一次永远不应当出现在表名中。
eg: customer与customerObject、accout与accountData、theMessage与message都没区别
- 使用读得出来的名称
人类大脑有一块地方可以用来容纳和处理单词。eg:generationTimestamp
- 使用可搜索的名称
长名称胜于短名称。若变量和常量可能在代码中多处使用,则应赋其以便于搜索的名称。
- 避免使用思维映射
不应当让读者在脑中吧你的民盛翻译为他们熟知的名称。
- 类名
类名和对象名应该是名词或名词短语
- 方法名
方法名应当时动词或动词短语
- 每个概念对应一个词
- 别用双关语:避免将同一个单词用于不同目的。
- 使用解决方案领域名称
- 使用源自所涉问题领域的名称
- 添加有意义的语境:精确正是命名的要点
第三章 函数
- 短小
函数第一规则是短小,第二规则还是短小。二十行最佳
- 只做一件事
函数应该做一件事。做好这件事。只做一件事。
- 每个函数一个抽象层级
自顶向下读代码:向下规则
- switch 语句
利用多态来实现这一点
- 使用描述性的名称
别害怕长名称。长而具有描述性的名称,要比描述性的长注释好。
-
函数参数 最理想的函数参数为零
- 一元函数
- 标识参数
- 二元函数
- 三元函数
- 参数对象
- 参数列表
- 动词与关键字
-
无副作用
-
分割指令与询问
-
使用异常替代返回错误码
- 抽离try/catch块
- 错误处理就是一件事
-
别重复自己
重复坑你是一切邪恶的根源
- 结构化编程
- 如何写出这样的函数
分解函数、修改名称、消除重复
第四章 注释
若编程语言足够有表达力,或者我们长于用这样的语言来表达意图,就不那么需要注释。注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。
第五章 格式
保持良好的代码格式
垂直格式
- 垂直方向上的区隔
每个空白行都是一条线索,标识出新的独立概念
-
垂直方向上的靠近
-
垂直距离
理解系统做什么,关系密切的概念互相靠近。自顶向下贯穿源代码模块的良好信息流
* 变量声明:变量声明应尽可能的靠近其使用位置。因为函数很短,本地变量应该在函数的顶部出现。
* 实体变量:应该在类的顶部声明
* 相关函数:若某个函数调用了另外一个,就应该把它们放在一起,而且调用者尽可能放在被调用者上面。
* 概念相关:概念相关的代码应该放到一起。相关性越强,彼此之间的距离就该越短。
横向格式
第六章 对象和数据结构
面向对象代码便于在不改动既有函数的前提下添加新类
数据传输对象
数据传输对象(DTO):最为精炼的数据结构,是一个只有公共变量、没有函数的类
第七章 错误处理
错误处理很重要,但如果它搞乱了代码逻辑,就是错误的做法。
- 使用异常而非返回码
- 先写Try-Catch-Finally语句
- 使用不可控异常(unchecked exception)
- 给出异常发生的环境说明
- 依调用者需要定义异常类
- 定义常规流程
- 别返回NULL值
public List<Article> findAll(String condition) throws Exception {
List<Article> all = articleMapper.findAll(condition);
if (ListUtils.isEmpty(all)) {
return Collections.emptyList();
}
return all;
}
上层调用的时候避免过多的非空判断,让代码看起来整洁
第八章 边界 (已看)
学习性测试
第九章 单元测试
第十章 类 (优先看)
下一篇: 新规要求工业机器人产品保修期不少于1年