阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://new.qq.com/omn/20181009/20181009A0V2HC.html 「无名」欢迎转载，保留摘要，谢谢！

• 可读性
• 格式
• 死代码
• 嵌套代码
• 使用对象
• 大型代码块
• 命名规则
• 删除注释#
• 合理的返回
• 三的原则
• 对称性

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

这是一篇值得收藏起来，隔三差五就拿来重读的文章！因为作者向你保证，他“遇到的所有糟糕的代码，都是因为没采纳这些实践经验。而任何一段优秀的代码，都采纳了至少部分实践经验。”

还等什么？赶快看看这些经验就是什么吧？

我已经写了20年代码了，在此期间曾与17个团队共事过，使用不同的语言做过数百个项目。

这些项目从最简单的博客网站，到支持每秒3000多次请求的API，还有曾经热卖过的应用。

根据这些经验，再结合我读过的书，我认为编程中最重要的是：# 可读性。#

可读性

表面上看来，可读性似乎很主观。不同语言、代码、和团队对于可读性的定义不尽相同。但如果深入本质的话，就会发现代码可读性有一些非常关键的因素。

许多程序员太倾向于计算机了，只要程序能运行就一了百了。尽管是老生常谈，但这种方式完全断绝了人参与的可能性。

最近几个月， 我在努力将这些人为因素提炼成11条写程序的实践经验，专门讨论如何增强可读性并降低复杂度。

我在BaseCode中写过这些详细内容，并将其应用到真实世界的代码片段中。

许多人会认为这些太基础、无关紧要，可以忽视。但我可以向你保证，我遇到的所有糟糕的代码都是因为没采纳这些实践经验。而任何一段优秀的代码都采纳了至少部分实践经验。

格式

我们在格式上消耗了太多精力。制表符还是空格，Allman还是K&R。总会有一天，你会意识到格式在编程中并不是最重要的。

选择一种格式，应用到代码中，然后将这个过程自动化。然后就可以重新专注于写代码本身了。

死代码

所有注释掉的代码块、未使用的变量和无法到达的的代码都是垃圾。他们就像在对读者说，“我不关心这段代码”。

于是恶性循环开始了。日复一日，死代码最终会埋葬你的代码。这正是经典的破窗效应。

必须要找出并干掉死代码。虽然不需要把精力主要放在这里，但一定要时时留意。

嵌套代码

逻辑几乎是一切代码的基础。我们写代码是为了做决策、迭代和计算。一般情况下都会导致分支或嵌套，从而造成嵌套得很深的代码块。

虽然计算机很容易阅读这种代码，但对于人类则是非常大的精神负担。因此，代码会变得复杂、难以阅读。应该通过防御语句、提前返回或使用函数式编程等方式消灭嵌套代码。

使用对象

尽管现在是面向对象编程的时代，我们依然使用了过多的原始指令。

长长的参数列表，杂乱的数据，自定义的数组或字典结构等。这些都可以重构成对象。

这样不仅能让数据结构变得正规，还能容纳所有重复的、使用原始数据的重复的逻辑。

大型代码块

虽然没有具体的数字，但代码块的长度应该是有限制的。如果你认为你的代码块过大，就应该对其进行识别、重组并重构。

这个简单的过程可以让你确定代码块的上下文和抽象级别，以便正确地找出代码的任务，并将代码重构到更加易于阅读、更简单的代码块中。

命名规则

当然，好的命名很困难，但只是因为我们人为增加了难度。有个小技巧在编程的许多方面都能用得上，包括命名，那就是——延后。不要纠结某个东西的命名，继续写代码就好。

就算是用一整句话命名一个变量都没问题，继续写代码就好。我可以保证，当你完成整个功能之后，更好的名字就会浮出水面。

删除注释#

在我看来这一条至关重要，删了注释我才能把精力放到可读性上。不管我如何解释删除注释的必要性，总会有人跟我抬杠，然后举出一个绝对需要注释的例子。

当然，如果哈勃望远镜要和古老的适配器连接，而后者返回一个意思不明的687，这种情况肯定需要注释来说明。但大多数其他情况下，你应该尽量重写代码使得它不需要注释也能看懂。

合理的返回

我们总是选择返回最奇怪的值，特别是对于边界条件的情况。像-1、687或null。然后就得写很多代码来处理这些值。实际上，null的创造者称它为“10亿美元的错误”。

应该努力返回更有意义的值。理想情况下，最好是即使在反面情况下也能让调用者继续执行的值。如果真的是异常情况，那么最好用其他方式来通信，而不是使用null。

三的原则

考虑一下数学上的序列。给出数字2并问你，“下一个数字是什么？”可能是3可能是4，但也可能是1或2.1。实际上你没办法知道。然后我提供了序列中的下一个数字2, 4然后问，“下一个是什么？”可能是6，8，也可能是16。

同样，尽管猜对的可能性增加了，但还是不能确定。然后我提供了数列中的第三个数字，2, 4, 16，然后问“下一个是什么？”有了三个数字之后，程序员的大脑很容易看出这是个平方序列，于是确定下一个数字是256。这就是三的原则。

这个例子虽然跟编程没关系，但它告诉我们，我们不应该太早做抽象。三的原则能阻止我们过早消除重复的努力，直到有了足够多的信息后再做出决定。用Sandi Mets的话说，“重复的代价远远低于错误的抽象。”

对称性

最后一条实践经验能给所有代码的可读性带来诗一般的润色，那就是对称性。这条来自Kent Beck的《实现模式》一书，书中说到：

代码中的对称性是说，同样的思想在任何地方都使用同样的实现。

不过说起来容易做起来难。对称性体现了编程的创造性。它是许多其他实践的基础：命名、结构、对象、模式等。不同语言之间、不同代码之间和不同团队之间对于对称性的定义都可能不一样。

因此，你需要花上许多年去追求对称性。但是，一旦开始在代码中使用对称性，就会迅速呈现纯粹的形式，代码的形状也会迅速变好。