代码不仅是用来运行的，还会给很多人阅读，包括你自己。为了能让人更容易看懂代码，需要尽量把代码写得更通俗易懂。要把写代码看成是写一篇文章，好的文章会让人觉得读起来非常轻松，如行云流水，不知不觉一口气就读完了。不好的文章读起来如同嚼蜡，看两三行就不想看下去。

很多人可能都遇到过下面这样的场景：

那如何才能让代码更容易阅读呢？

首先，要注意排版

在写代码时注意排版，保持一致的缩进风格，并利用空行划分段落，可以让代码看起来更整洁，逻辑更清晰。

在一个较复杂的方法中，将方法中各个处理步骤用空行进行分隔，可以让代码具备很好的可读性。如果一个方法中几十行代码完全没有分隔，密密麻麻挤在一起，阅读这段代码会让人感觉像是在看一篇没有标点符号的文章，让人喘过不气来。

下面这段代码，正确使用了空行进行分隔，看起来非常轻松。

但如果去掉空行，就是下面这个效果，看起来非常有压迫感

合适的空行，让阅读者知道上一个处理步骤已结束，开始下一个处理步骤了。在阅读代码时，就可以按空行跳跃进行查看，快速找到关注的点。

统一的缩进格式会让代码看起来整齐划一，非常清爽。阅读这样的代码时，会让人心情愉悦，频频赞许。

其次，让代码具备自描述性

好的代码应该具备自描述性。正如上面提到的，阅读代码就像是阅读一篇文章，好的文章是不需要一边看内容，一边看下面的脚注来理解的。

在接手一个项目时，被吐槽最多的是代码没有注释。但注释过多也是另一个极端，不应该被提倡。过多的注释也会成为项目的一个负担，每次修改代码时必须要记得同步修改注释，如果忘记修改注释，出现注释和代码不一致的情形，就会让人对注释失去信任。经常出现这样的情况，就会让开发变得越来越不愉快了。

当打算写注释时，先思考一下，这里是否能用代码本身来把逻辑表达出来。在确定这是一种特殊情况，需要交代为何如此处理的背景信息时，才应该写注释。正常情况下，都可以通过方法，变量的命名来描述清楚。

比如下面这样的代码，命名，结构都非常清晰易懂

有时为了想一个好名字也要花上一些时间，但这是值得的。良好的命名可以让代码更加易读。类名，方法名，参数名，变量名都是我们可以利用的载体，可以通过这些名称来把代码逻辑表达出来。

这里再举一个例子来说明如何用变量名来描述代码逻辑：

下面这段代码中 if 条件的逻辑非常复杂，如果没有注释是不容易看懂编写者的意图的

但如果写成下面这样就很容易阅读了

最后，可以做的还有很多

让代码简洁易读并不容易，大道至简，是要花很多心思的，这个话题也不是一篇短文可以讲完的。这里再提供几个小方法，希望可以起到抛砖引玉的作用。

• 一个方法只做一件事情，并保证方法名准确，参数及返回值明确

一个方法应尽可能短，非必要不要超过 80 行。当超过时，就需要提醒自己，是不是在方法中承担了过多的事情。

• 不要通过参数控制方法内部的处理逻辑

经常会遇到这样的方法，当参数 a = true 时按 A 逻辑处理，当 参数 a = false 时按 B 逻辑处理。 这样做其实就违反了上一条，让一个方法做了多件事情。这种情况下方法命名都会有问题，无法用名字准确表达方法的功能。这时就应该把两种逻辑拆分到两个方法中。哪怕这样会导致一些重复代码也是值得的。

• 当业务逻辑比较复杂时可以考虑进行封装

当业务逻辑比较复杂需要多个步骤才能完成时，这种情况大多数都可以把这块业务逻辑单独封装为一个类，对外只公布几个入口方法，其它内部逻辑的实现拆分到类中的多个私有方法中。 比如对用户提交的查询条件进行分解时，涉及时间范围条件，单选条件，多选条件等等，就可以构建一个查询条件解析类，传入客户端提交的原始数据，返回分解后的结构化条件。

上面这些方法，都可以起到让代码更容易阅读的作用。好的代码和好的文章一样，需要不断打磨推敲，不是一蹴而就的。不过大多数程序员工作压力都比较大，需要加班赶工。这个时候再提打磨推敲代码，就有点何不食肉糜的味道了。希望整个环境能越来越好，大家能少加班，有更多的时间优化重构自己的代码。