前言
最近在团队推行 Code Review，遇到一个头痛的问题。当向伙伴的代码提一个 comment 时，他们不解为什么需要这样改。细细想来，是他们不知道何为好代码，也不知道自己的代码有哪些 “坏味道”。因此，分享了几期 Clean Code，团队受益良多，故成此文。
Clean Code
由于 Clean Code 篇幅较长，故先安排如下我认为较为重要的几点：
- 命名
- 函数（方法）
- 注释
- 对象、数据结构
- 类
命名
命名有许多规则，但总结起来就是 “有意义” 才是硬道理。
名副其实
1
Int d；//逝去的时间
这句代码的问题在于 d 没有表达好逝去的时间这个概念，故需要注释。请记住“名副其实就不需要注释”
1
Int elapsedTime;
再来看个例子
谁都很难猜出其意义，看看小优化后的结果
基本看清了意义，这就是命名的重要性。细心的朋友还会发现这段代码的一些瑕疵 ：这里的 4 是什么鬼？习惯性我们管它叫“魔法数字”
还是觉得有点问题，再优化
对比下最早的代码，相信你会有感觉了。
避免误导
生活中的场景也常出现在 Code 中，看下图，你的 Code 是否也出现这样的尴尬呢？那就 Make it clean
是否傻傻分不清了呢？ 再来个
1
accountList
我知道你想说，这有什么问题。是的，如果你不是做 Java 开发，不会知道链表叫 List，所以如果你不是用链表存储 account，请不要用其修饰，或许这个时候你使用 acountGroup 会更好些。 该点需要在具体开发环境下因地制宜
有意义的区分
1
2
3
Product
ProductInfo
ProductData
可以想象下，当一个项目中同时出现以上三个类的时候，你是如何区分开的，反正我是没有这个能力。类似的还有
1
2
game
theGame
1
2
name
nameString
分享时，伙伴说 nameString 有什么问题。我反问说难道你的名字会是 Float 型的？你懂了吧。
前缀
1
m_desc
有人提出加 m 前缀表示该变量为私有变量。 我想说：你的变量很多？需要区分私有的还是公有的？如果你的变量很多，那就要想想是不是没设计好类，没有遵循单一职责原则，另外私有和公有变量编译器会帮忙高亮显示区分的，不需要自己来区分(若某些编译器无此特性，怪编译器去)。
命名惯性
命名需要注重词性 类名：名词 or 名词短语 方法名: 动词 or 动词短语
每个概念对应一个词
在一个模块中不要使用两个相似的概念来表达不同的操作。我在一份代码中看到过一个类中同时出现以下三个词打头的方法
1
2
3
fetch
get
retrieve
请问那个才是真的获取值的方法？我实在分不清。
使用领域名称
使用领域命名能让伙伴更明白你的程序结构（关于领域这个概念，不熟悉的可以看下一本书叫 《领域驱动设计》,俗称 DDD） 举个例子，比如你使用访问者模式来构建用户系统，那么
1
AccountVisitor
就显得明确、易懂
抵制缩写诱惑
缩写需要注意，适当的缩写是可以的，但是要保证缩写后的词语仍然能表达其本意。举个有意思的例子
1
ABCDEFG
这也是个缩写，但是乍看这个真不知道是什么的缩写，直接公布答案吧
小结
命名是永恒的难题，我提几个建议吧
- 多看开源代码，积累好的用词
- 不懂的词就查下词典，好过你自己想的
- 做个自己的开源项目，让别人给你建议
- 做好积累、再积累、还是积累
函数（方法）
函数的第一条规则是要短小，第二条规则还是要短小。
短小
那到底多短合适呢？历史上出现过几个标准
- 一屏
- 100 行
- 50 行
- 20 行 有人问我为什么会差这么多，我的回答是：以前的屏幕分辨率那么低，一屏也就 20-50 行之间吧，所以以前一屏的说法也是合理的。 对于行数，行业没有一个固定的标准。我所知道的 Oracle 建议是 50 行，Bob 大叔的建议是 20 行。
代码短小，好处自然很多。
- 单元测试覆盖率高
- 每个函数一目了然，只做一件事
- 有利于函数中的代码都在同一个抽象层级
只做一件事
函数应该做一件事。做好这件事。只做一件事。 那么如何判断只做一件事？
请问这个函数做了几件事？伙伴的答案是
1
2
3
1.判断是否为测试页面
2.加入测试数据
3.渲染页面
你的答案是多少呢？其实答案是只做了一件事，主要是没有看清 一件事 OR 一件事的多个步骤，关于这点，大家要好好体会。
另外一个判断是否只做一件事的好方法： 是否能再次分离出新函数
同一个抽象层级
关于层级，比较难讲明，直接看例子吧
再看一个版本
你会发现看第二个版本的代码，明显舒服很多。因为第二的版本的三句代码都在同一个层级。而第一个版本的代码中的第一句是设置 roundView 的某个属性，但是最后一句却是在设置 bubbleView，层级不同（roundView 与 bubbleView 才是同层级）
使用描述性名称
如果长一点的名称可以更加清晰，不要犹豫，用清晰的吧（注意是要有意义的）
1
2
calculate
calculatePrice
相比起来 calculatePrice 就好很多。 再来看个例子
1
2
addComment
addCommentAndReturnCount
你不是说长一点更清晰吗，那 addCommentAndReturnCount 很好吧。 关于这点大家要注意，如果你需要用 and、or 之类的介词来修辞函数时，要考虑下你是否违背了单一职责原则
参数个数
0 个最好， 1 个次之， 2 个还行， 3 个以上不是太好了。 参数与函数名位于不同的抽象层级，它要求你必须了解目前并不特别重要的细节。 解决办法有许多，比如某些场景可使用DTO
嵌套层次、分支过多
嵌套、分支过多会让代码变得很难理解，解决的办法有如下：
- 卫语句
- do-while,引入 break
- if-else if-then
- 提取函数
- 以子类取代类型代码
- 以多态取代条件式
- … 具体可根据项目特点选用
分割指令与查询
set 这个函数很不明确的是到底是设置成功了返回 true，还是名字存在返回 true，但真正的问题在于，它是个指令但是掺杂了查询的功能。
将查询和命令分离后，代码便清晰很多了。
小结
如何写出好的函数
- 先写对的，再写好的
- 对 =》 单元测试 =》识别坏味道 =》重构
注释
“别给糟糕的代码加注释 — 重新写吧。” –Brian & P.J. “注释总是一种失败” –Bob
用代码来阐述
感受两段代码会发现代码即注释的美
坏注释
先来看看什么是坏的注释
喃喃自语
这注释绝对是给自己看的
多余的注释
解释跟没解释一样，不如代码来的简单明了
误导性的注释
你在误导吧
循规式注释
这个一定要注意，循环式的注释完全多余（除了做 sdk、开源）
括号后的注释
如果括号后需要注释，只表明你这段代码太长了，需要做的不是加注释，而是将它变短。
归属于署名
Git、SVN 知道是你提交的，不用这样刷存在感
注释掉代码
注释掉的代码，只会让修改你代码的人蒙圈，如果你觉得这段代码有可能以后会用，也不用担心，Git、SVN 会帮你找回来
信息过多
面向对象讲究，暴露操作，隐藏实现，如果你还要注释这些信息，表示你没有封装好。这些信息，可考虑放个链接或者其他的简短提示，太长的注释，别人懒得读、也难读懂
好注释
看了那么多坏注释，来看看什么是好的注释
法律信息
提供信息
对意图的注释
阐释
警示
TODO 注释
放大
对象、数据结构
数据抽象
将变量设置为私有(Private)，主要是不想让其他人依赖这些变量。所以，不要随便给变量添加赋值方法和取值方法(set/get 方法)，这样其实是把私有变量公之于众。 隐藏变量和实现，并不是在变量与外界之间放一个函数层那么简单。隐藏关乎抽象。 类并不简单地用赋值方法和取值方法将其变量推向外间，而是暴露抽象接口，以便用户无需了解数据的实现而能操作数据本体。 要以什么方式呈现对象所包含的数据，需要做严肃的思考。随便加赋值方法和取值方法，是最坏的选择。
数据、对象的反对称性
前者是一种过程式代码，后者是面向对象式代码。我们会发现假如要添加一个新形状的话，后者绝对是不错的选择，因为以上代码都不需要修改，只需写一个新形状类，这符合“开放–封闭”原则。然而假如添加一个计算周长的功能的话那就杯具了，因为这样子每个形状类都得改动。但是假如是用过程式代码的话只需要添加一个新函数。
过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数。 面向对象代码便于在不改动既有函数的前提下添加新类。 一切都是对象只是一个传说
类
组织
- 公共静态变量
- 私有静态变量
- 私有实体变量
- 公共函数
- 私有函数 自顶向下原则 这里为什么没有写公有实体变量是因为，其不建议出现在代码中。
短小
函数的短小标准是行数，那类是什么呢？答案是职责 类需要遵循单一职责原则
内聚
如以上代码，内聚性高，除了 size 方法外，其他方法都使用了两个实例变量。 内聚：模块内部各个元素彼此结合的紧密程度（类中方法和变量间的结合程度） 保持内聚会得到许多短小的类 当一个类丧失内聚性时我们应当拆分它
总结
Clean Code 能帮助团队构建代码质量体系，有助于开发的各个环节（静态分析、持续集成、Code Review…）。当然，对个人的能力提高也很有好处，建议大家都应该熟悉。等团队 Code Review 一段时间后，有其他收获的话，再给大家分享。 预祝大家国庆节快乐！
聊聊设计模式原则（二） -- 接口隔离原则