共计 3947 个字符，预计需要花费 10 分钟才能阅读完成。
留神了，这篇教你如何写出不让共事无奈保护的代码！作者：xybaby，原文：https://www.cnblogs.com/xybab…
写出整洁的代码，是每个程序员的谋求。《clean code》指出，要想写出好的代码，首先得晓得什么是恶浊代码、什么是整洁代码；而后通过大量的刻意练习，能力真正写出整洁的代码。
WTF/min 是掂量代码品质的唯一标准，Uncle Bob 在书中称蹩脚的代码为沼泽（wading），这只突出了咱们是蹩脚代码的受害者。国内有一个更适宜的词汇：屎山，尽管不是很斯文然而更加主观，程序员既是受害者也是加害者。
对于什么是整洁的代码，书中给出了巨匠们的总结：
- Bjarne Stroustrup：优雅且高效；含糊其辞；缩小依赖；只做好一件事
- Grady booch：简略间接
- Dave thomas：可读，可保护，单元测试
- Ron Jeffries：不要反复、繁多职责，表达力（Expressiveness）
其中，我最喜爱的是表达力（Expressiveness）这个形容，这个词仿佛道出了好代码的真谛：用简略间接的形式描绘出代码的性能，不多也不少。
命名的艺术
坦率的说，命名是一件艰难的事件，要想出一个恰到好处的命名须要一番功夫，尤其咱们的母语还不是编程语言所通用的英语。不过这一切都是值得了，好的命名让你的代码更直观，更有表达力。
好的命名应该有上面的特色：
货真价实
好的变量名通知你：是什么货色，为什么存在，该怎么应用
如果须要通过正文来解释变量，那么就先得不那么货真价实了。
防止误导
- 不要挂羊头卖狗肉
- 不要笼罩习用缩略语
这里不得不吐槽前两天才看到的一份代码，竟然应用了 l 作为变量名；而且，user 竟然是一个 list（单复数都没学好！！）
有意义的辨别
代码是写给机器执行，也是给人浏览的，所以概念肯定要有区分度。
- 应用读的进去的单词
如果名称读不进去，那么探讨的时候就会像个傻鸟
- 使用方便搜寻的命名
名字长短应与其作用域大小绝对应
- 防止思维映射
比方在代码中写一个 temp，那么读者就得每次看到这个单词的时候翻译成其真正的意义
正文
有表达力的代码是无需正文的。
The proper use of comments is to compensate for our failure to express ourself in code.
正文的适当作用在于补救咱们用代码表白用意时遇到的失败，这听起来让人丧气，但事实的确如此。The truth is in the code, 正文只是二手信息，二者的不同步或者不等价是正文的最大问题。
书中给出了一个十分形象的例子来展现：用代码来论述，而非正文
bad
// check to see if the employee is eligible for full benefit
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))
good
if (employee.isEligibleForFullBenefits())因而，当想要增加正文的时候，能够想想是否能够通过批改命名，或者批改函数（代码）的形象层级来展现代码的用意。
当然，也不能因噎废食，书中指出了以下一些状况属于好的正文
- 法务信息
- 对用意的正文，为什么要这么做
- 警示
- TODO 正文
- 放大看似不合理之物的重要性
其中集体最同意的是第 2 点和第 5 点，做什么很容易通过命名表白，但为什么要这么做则并不直观，特地波及到专业知识、算法的时候。
另外，有些第一感觉“不那么优雅”的代码，兴许有其非凡违心，那么这样的代码就应该加上正文，阐明为什么要这样，比方为了晋升要害门路的性能，可能会就义局部代码的可读性。7 点倡议助您写出优雅的 Java 代码！这篇也能够看下。
最坏的正文就是过期或者谬误的正文，这对于代码的维护者（兴许就是几个月后的本人）是微小的挫伤，惋惜除了 code review，并没有简单易行的办法来保障代码与正文的同步。
函数
函数的繁多职责
一个函数应该只做一件事，这件事应该能通过函数名就能清晰的展现。判断办法很简略：看看函数是否还能再拆出一个函数。
函数要么做什么 do_sth, 要么查问什么 query_sth。最恶心的就是函数名示意只会 query_sth, 但事实上却会 do_sth, 这使得函数产生了副作用。比方书中的例子
public class UserValidator {
private Cryptographer cryptographer;
public boolean checkPassword(String userName, String password) {User user = UserGateway.findByName(userName);
if (user != User.NULL) {String codedPhrase = user.getPhraseEncodedByPassword();
String phrase = cryptographer.decrypt(codedPhrase, password);
if ("Valid Password".equals(phrase)) {Session.initialize();
return true;
}
}
return false;
}
}函数的形象层级
每个函数一个抽象层次，函数中的语句都要在同一个形象层级，不同的形象层级不能放在一起。比方咱们想把大象放进冰箱，应该是这个样子的：
def pushElephantIntoRefrige():
openRefrige()
pushElephant()
closeRefrige()函数外面的三句代码在同一个层级（高度）形容了要实现把大象放进冰箱这件事程序相干的三个步骤。显然，pushElephant 这个步骤又可能蕴含很多子步骤，然而在 pushElephantIntoRefrige 这个层级，是无需晓得太多细节的。
当咱们想通过浏览代码的形式来理解一个新的我的项目时，个别都是采取广度优先的策略，自上而下的浏览代码，先理解整体构造，而后再深刻感兴趣的细节。
如果没有对实现细节进行良好的形象（并凝练出一个货真价实的函数），那么阅读者就容易迷失在细节的汪洋里。
某种程度看来，这个跟金字塔原理也很像
每一个层级都是为了论证其上一层级的观点，同时也须要下一层级的反对；同一层级之间的多个论点又须要以某种逻辑关系排序。pushElephantIntoRefrige 就是核心论点，须要多个子步骤的反对，同时这些子步骤之间也有逻辑先后顺序。
函数参数
函数的参数越多，组合出的输出状况就愈多，须要的测试用例也就越多，也就越容易出问题。
输入参数相比返回值难以了解，这点深有同感，输入参数切实是很不直观。从函数调用者的角度，一眼就能看出返回值，而很难辨认输入参数。输入参数通常逼迫调用者去查看函数签名，这个切实不敌对。
向函数传入 Boolean（书中称之为 Flag Argument）通常不是好主见。尤其是传入 True or False 后的行为并不是一件事件的两面，而是两件不同的事件时。这很显著违反了函数的繁多职责束缚，解决办法很简略，那就是用两个函数。
Dont repear yourself
在函数这个层级，是最容易、最直观实现复用的，很多 IDE 也难帮忙咱们讲一段代码重构出一个函数。
不过在实践中，也会呈现这样一种状况：一段代码在多个办法中都有应用，然而又不齐全一样，如果形象成一个通用函数，那么就须要加参数、加 if else 区别。这样就有点难堪，貌似能够重构，但又不是很完满。
造成上述问题的某种状况是因为，这段代码也违反了繁多职责准则，做了不只一件事件，这才导致不好复用，解决办法是进行办法的细分，能力更好复用。也能够思考 template method 来解决差别的局部。
测试
十分羞愧的是，在我经验的我的项目中，测试（尤其是单元测试）始终都没有失去足够的器重，也没有试行过 TDD。正因为缺失，才更感良好测试的宝贵。
咱们常说，好的代码须要有可读性、可维护性、可扩展性，好的代码、架构须要不停的重构、迭代，但自动化测试是保障这所有的根底，没有高覆盖率的、自动化的单元测试、回归测试，谁都不敢去批改代码，只能任其腐烂。
即便针对外围模块写了单元测试，个别也很随便，认为这只是测试代码，配不上生产代码的位置，认为只有能跑通就行了。这就导致测试代码的可读性、可维护性十分差，而后导致测试代码很难追随生产代码一起更新、演变，最初导致测试代码生效。所以说，脏测试 – 等同于 – 没测试。
因而，测试代码的三要素：可读性，可读性，可读性。
对于测试的准则、准则如下：
- You are not allowed to write any production code unless it is to make a failing unit test pass. 没有测试之前不要写任何性能代码
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 只编写恰好可能体现一个失败状况的测试代码
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test. 只编写恰好能通过测试的性能代码
测试的 FIRST 准则：
- 疾速（Fast）测试应该够快，尽量自动化。
- 独立（Independent）测试应该应该独立。不要相互依赖
- 可反复（Repeatable）测试应该在任何环境上都能反复通过。
- 自我验证（Self-Validating）测试应该有 bool 输入。不要通过查看日志这种低效率形式来判断测试是否通过
- 及时（Timely）测试应该及时编写，在其对应的生产代码之前编写
