《编写可读代码的艺术》总结

花了一天时间将《编写可读代码的艺术》读完，这边对书中提到的知识点做下总结。

《编写可读代码的艺术》的核心在于通过各种方式实现代码的高可读性。

那么怎么评判可读性？

你只要找一个对项目一点都不了解的人(但至少要有一定的编程知识)，然后看他需要多长时间理解这段代码并可以做修改，而这个时间的长度就是可读性的高低。

怎么提高代码的可读性？

书中通过三个层面分别进行讲解：

书面层面
流程控制层面
代码结构层面

书写层面

命名

* 类命名
* 字段命名
* 方法命名

好的命名可以带来什么好处？

更容易记忆
提供更多信息

相比于字段 a 来说字段 age 能够更让人记忆深刻，而且提供了更多的信息。age 的含义是年龄的意思，而 a 你能说明它代表什么意思吗？

但是 age 提供的信息还不够完整，它到底是谁的年龄呢？学生? 老师 ? 还是男孩？这个时候有两种方式，一种是直接在字段上体现：

// 学生年龄
int studentAge;

或者是联系上下文看它属于什么对象：

// 学生实体类
public class Student{
	int age;
}

相对于类和属性来说，方法上的有效命名性价比更高。通过好的命名你就知道这个方法的作用了，而不需要深入代码中研究半天才能理解这个方法的作用。

比如方法 sendUserRegistrationInfo 比起 send 来说更能让调用者理解这个方法的作用，前者能很明显的告诉调用者这是一个发送用户注册信息的方法，而后者需要调用者自己研究下到底发送了什么信息。

好坏命名的区别

我们知道了命名的好处，但是为什么我们经常感受不到这些好处呢？是因为命名也有好有坏，不好的命名不仅没有带来这些好处，相反还给我们增加了额外的负担，如：

名字过长
空泛的命名
多重含义的命名

名字过长

名字过长会造成记忆负担，而造成这种情况的原因一般如下：

* 1.对于所要做的事情没有清晰的认识
* 2.所做的事情太多导致不能清晰的表达

对于第一点来说我的建议是在重新整理下需求，对于第二点的解决方法是将它拆分成多个方法，每个方法只做一件事。

空泛的命名

像 a、b、c 这种没有含义的命名实在是没有出现的必要，但是在 for 循环中的 i 为什么不会引起这种问题呢？

原因是因为它的作用域很小，并且它的使用已经算是一种约定俗成的习惯，不会引起使用者的误解。

多重含义的命名

多重含义的命名带来的就是容易让人误解，到底我这个方法是要做什么行为呢？在不同的语境下相同的词常常会南辕北辙。如果你想不到好的词的话，留下一段注释可能也不失为一种解决办法。

注释

注释的作用如下：

对代码行为做一个概括描述
对代码未体现的事情做个描述
对未完成的事做备注

基于以上两点可以看出好的注释的特征：

* 1.不是所有的行都需要注释
* 2.代码可以自体现的就不需要额外的注释(类、方法上面还是建议有概括性注释)
* 3.不同逻辑间可以做一个概括性描述，让人更容易理解代码逻辑

代码格式

代码格式对于可读性来说很重要，幸好目前的 IDE 都有智能格式化代码样式功能，所以这点对我们来说不需要太多的关注。

简化循环

我们先来看看常用的流程控制逻辑语法：

if else
for
do .. while 和 while
三目表达式

if else

程序中 if else 判断自然是避免不了的，但是多重嵌套的 if else 判断实在不是一种可读性很好的编写方式：

Order order = orderMapple.selectByPrimaryKey(orderId);
if(order != null){
	List<OrderItem> orderItemList = orderItemMapple.selectByPrimaryKey(orderId);
	if(orderItemList!=null && orderItemList.size()>=0){
		.............
	}
}

上面的代码实现了根据订单号获取订单信息，如果订单信息存在的话就获取订单行项目列表，如果订单行项目列表存在的话，就进行一系列的操作。

可以看到这样的多重嵌套在项目中是很频繁的操作，但是如果 “一系列” 操作逻辑比较多的话，一个屏幕的空间都显示不下这个 if 作用域。对于使用者的记忆会有比较大的负担，我们可以采用逆向思维方式的方式来改变下这个代码的结构：

Order order = orderMapple.selectByPrimaryKey(orderId);
if(order == null){
	return ;
}
List<OrderItem> orderItemList = orderItemMapple.selectByPrimaryKey(orderId);
if(orderItemList==null || orderItemList.size()<0){
	return ;
}
.............

可以看到采用这种结构就将多重 if 判断结构转为一重 if 判断，是不是更清晰点呢？

for

继续我们之前的例子，如果订单行项目是多行的话，我们通常使用 for 循环来取值进行操作：

List<OrderItem> orderItemList = orderItemMapple.selectByPrimaryKey(orderId);
OrderItem orderItem = null;
for(int i = 0,size = orderItemList.size; i < size; i++){
	orderItem = orderItemList.get(i);
	......
}

我们尝试另一种风格的 for 循环看看：

List<OrderItem> orderItemList = orderItemMapple.selectByPrimaryKey(orderId);
for(OrderItem orderItem : orderItemList){
	......
}

是不是比第一种可读性更好呢？当然选择哪种风格的 for 循环可以根据使用场景来决定，有时候第一种风格可能更好。

do .. while 和 while

do .. while 和 while 的功能是一样的，唯一的区别在于 do .. while 不管条件是否成立都会执行一次作用域里的代码，而 while 必须条件成立才会执行。

通常我们都会从前往后读取代码，而 do .. while 会让人重复读两边代码（因为条件在最下面，导致会在看到条件后再重新读一遍逻辑）。所以书中建议最好不要使用 do .. while 而采用修改 while 条件的形式。

三目表达式

三目表达式是为了避免写如下代码而出现的：

if(a > b){
	return a;
}else{
	return b;
}

三目表达式形式如下：

return a > b ? a : b;

可以看到三目表达式更简洁，但这是针对于表达式比较简单的逻辑，如果是逻辑比较复杂的可读性会变的相当差：

return a > b ? xxx(a,z) : yyy(b,z);

在这里，三目表达式已经不只是从两个简单的值中做出选择，可读性已经变得不是很好。针对这种情况采用 if else 的方式会更好，虽然代码量增加了，但是可读性同时也增加了。

结构层面

拆分超长的表达式
让方法只做一件事
复用代码实现少些代码

拆分超长的表达式

if(orderType != "0021" && orderType != "0022" 
	&& orderType != "0033" && orderType != "0034"
	&& orderType != "0043" && orderType != "0044"){
	......
}

如上所示，在项目中应该也会经常看到这种代码吧，单据类型不同所走的逻辑也不同。我们来做下调整：


if(isOtherOrder(order.getOrderType())){
	......
}

public boolean isOtherOrder(String orderType){
	List<String> orderTypeList = new ArrayList();
	orderTypeList.add("0021");
	orderTypeList.add("0022");
	orderTypeList.add("0033");
	orderTypeList.add("0034");
	orderTypeList.add("0043");
	orderTypeList.add("0044");
	return orderTypeList.contains(orderType);
}

是否可读性更好了，而且之后如果单据类型增加了，也只需要在 isOtherOrder 方法中增加即可。

让方法只做一件事

在之前我们讲命名过长的时候就已经讲到了要让方法只做一件事情。一方面是可以之后的复用，另一方面是为了更好的明确职责。

复用代码实现少些代码

减少程序 bug 最好的方式就是不写代码，当然这是不太可能的事。为了尽量达到这个目的，复用代码是不可缺少的一件事。