语言的易读性 // Shell's Home

何谓语言的易读性，简单来说，就是看到一段代码的时候，能够了解其意思。易读性最差的典型代表作是汇编语言和机器语言，因为在读这两种语言的时候，其实是你的大脑在替代模拟CPU的功效。说起来，自从汇编以后，每种语言多多少少都注重了人类阅读的习惯，像brainfuck这种特例是万难一见的。例如下面的例子。

printf("hello, worldn");

即使没有任何C基础的人，也能够看懂这是在做一个字符串打印。

语言的易读性其实是语言非常重要的特征，比其他特征都重要。因为人类的大脑不可能记得所有的代码细节，并且能够直观的反应出如何修改。往往我们需要阅读一下代码，搞明白每段的意思，然后才能动手——哪怕这段代码出自自己手笔，只要过得一两个月，还是要重读一下的。正是因为读这个技能的使用频率非常高，所以语言的易读性非常直观的影响到语言的易用性。而易读性差的语言和习惯，目前来看有以下几个典型例子。

1.罗嗦

典型代表是Java。下面是一个Java解压Zip的代码，引用自参考1。

public class Zip{
	static final int BUFFER=2048;
	public static void main(String argv[]){
		try{

			BufferedInputStream origin=null;
			FileOutputStream dest=new FileOutputStream("E:testmyfiles.zip");
			ZipOutputStream out=new ZipOutputStream(
				new BufferedOutputStream(dest));

			byte data[]=new byte[BUFFER];
			Filef=new File("e:\test\a");
			File files[]=f.listFiles();
			for(int i=0;i<files.length;i++){
				FileInputStream fi=new FileInputStream(files[i]);
				origin=new BufferedInputStream(fi, BUFFER);
				ZipEntryentry=new ZipEntry(files[i].getName());
				out.putNextEntry(entry);
				int count;
				while((count=origin.read(data,0,BUFFER))!=-1){
					out.write(data,0,count);
				}
				origin.close();
			}
			out.close();
		}catch(Exceptione){
			e.printStackTrace();
		}
	}
}

我下面给出python版本。

import os, zipfile with zipfile.ZipFile(‘filename.zip’, ‘w’ ,zipfile.ZIP_DEFLATED) as zf: for name in os.listdir(’.’): zf.write(name)

罗嗦有什么坏处？当你需要理解一段代码的时候，需要上上下下翻动屏幕，并且仔细对比每个细节，才能理解这个代码的目的。这对于阅读来说是非常不友好的。

2.歧义

典型例子是++，我给出这么一个例子。

i = (++j) + (j++) + i---i

i是多少？脑子一团糨糊吧？关于自增自减的歧义，具体可以看参考2。当然，这并不是说C++设计的有问题，只是这个用法不可取而已。

歧义的最大问题是，不借助具体的实现运行一下，基本没有希望了解这个代码是什么意思。这哪里叫可读，这叫不可读。歧义是不可读中最差劲的一种，一切产生歧义的代码都是坏的代码，例如我们下面的这个例子：

import os
def os(os): return os

这个，return回去的到底是谁？os module？function？variable？运行一下我们知道，其实是返回了参数。但是这种代码骤然看到，鬼才能够反应的过来，写出这种代码的，上辈子都是非洲丛林里面的守林人，想bug想疯了吧。

还有一种是变量名类似，例如只以大小写区分，或者以下这个例子：

def sl(s1): return sl

您看出问题了么？没看出来？这到底要多脑残才会把变量弄的那么像函数名，导致return的时候把自己的函数给return回去阿？

3.依赖上下文

什么叫依赖上下文？其实这并不是一个很好界定的问题。无论代码多么简洁，我们都需要调用其他函数。这个函数就是所谓的上下文。在拥有一定知识的前提下，我们的代码越上下文无关越好。如果一定要上下文有关，这个相关部分越确定越好。例如C++中的一个例子：

DynamicFn<WM\_Hooks\_WMVAL\_proto> WM\_Hooks\_WindowChanged(\_T("wm\_hooks.dll"), "WM\_Hooks\_WindowChanged");

谁能告诉我，为了看懂这个代码，我需要查看多少内容？首先，我需要查看DynamicFn和WM_Hooks_WMVAL_proto的定义，然后去检查DynamicFn的构造函数。如果只有一个构造函数，并且参数类型匹配，那么很幸运，事情就到此为止。如果不匹配，我还得查看是否可以编译通过，如果可以，是匹配了哪个构造函数。如果都不匹配，那么肯定发生了内隐转换（implicit cast），如果有两个函数都可以通过内隐转换进行匹配，例如下面这种：

template <typename T>
DynamicFn::DynamicFn(wstring t, char \* c);
DynamicFn::DynamicFn(TCHAR \* t, string c);

天呐，这个不但依赖上下文，而且歧义了。更郁闷的是，随着UNICODE宏的变化，这两个函数的匹配行为还会产生变化。即使上面一切都没问题，您能够直观的从刚刚的一行代码中看出代码所要达到的目的么？从老程序员的习惯来猜测，好像是wm-hooks这个dll的WM_Hooks_WindowChanged函数进行SetHook，是不是，我懒得验证了。

比较好的解决这个问题的方法叫做代码自描述性。例如上文，这种文法是比较容易理解的。（但是不保证意义一致，因为上文我还不确定是安装Hook还是仅仅生成对象包装，或者两个行为同时实施了？下文也只是伪代码） create_function(u"wm_hooks.dll", “WM_Hooks_WindowChanged”) 4.晦涩何谓晦涩？高级特性过多。典型代表C++，谁来读一下这个代码？

#pragma once
#pragma lib("curl")

using namespace std;

#ifndef RFB_MAINTHREAD
#define RFB_MAINTHREAD

namespace rbf{
extern "C" {
	class MainThread: public Thread, EventHandler {
		MainThread (explicit HANDLE hFD);
		virtual ~MainThread();
		inline static int run_wrapper() { return run(); }
		virtual run() = 0;
	};
}
}

#endif//RFB_MAINTHREAD

OK，这段代码，就非常晦涩。其实老C++程序员都习惯这种晦涩的风格了，但是一般人还是会不知所云，必须去查手册。我们数数，这段代码用了多少奇怪的特性。

#pragma once // 这个是MSVC的一个宏，指头文件只被引用一次
#pragma lib("curl") // MSVC的宏，表示引入库

using namespace std; // 引入STL的标准命名空间
#ifndef RFB_MAINTHREAD//

虽然上面说只引用一次，但是为了兼容老的编译器，还是得定义一下，以防重复引用。

#define RFB_MAINTHREAD
namespace rbf{ // 自定义命名空间
extern "C" { // 虽然自己是C++，但是名称输出要符合C
	//多重继承，而且有点歧义的是，EventHandler按照默认规则，使用了private继承，你看出来了么？
	class MainThread: public Thread, EventHandler {
		MainThread (explicit HANDLE hFD); //explicit关键字，阻止内隐转换
		//虚析构函数，在多态重载的情况下，谨防某些编译器（例如Borland C++）上会调用不正确的析构函数，从而丢失内存
		virtual \~MainThread();
		// inline static，类静态函数可以被当作C函数等态启用，而C++类成员函数不可以
		inline static int run\_wrapper() { return run(); }
		virtual run() = 0; // 纯虚函数，必须被继承和重载
	};
}
}

#endif//RFB_MAINTHREAD

这已经算是把C++当C在写，只使用类，从而尽量避免引入高级特性了。纯正的C++程序员写出来的代码，我从effective STL摘一个例子出来看看。

v.erase(
	remove_if(
		find_if(v.rbegin(), v.rend(),
			bind2nd(greater_equal<int>(), y)
			).base(),
		v.end(),
		bind2nd(less<int>(), x)
		),
	v.end()
	);

看懂了么？实话说，我糊涂了。这一大段程序写的，怎么看怎么像lisp，偏偏又不像lisp那样，能把精力集中在问题本身上面，而要关注过多实现细节。

实话说，在编写和阅读时，必须注意如此多高级特性的语言，已经陷入为了解决一个问题不惜制造另两个问题的怪圈了。

总结在说这些语言问题的时候，应当注意，很多时候语言的问题并不是语言内在造成一定会出问题，而是现有的语言风格和社区，形成了不良的语言氛围。例如Java哪种绕口令般的架构风格，已经催生了架构师这个特殊职业。这个职业的主要工作，就是按照要求，产生很多类，以及描述，给其他人实现。

语言本身在设计时，一定会考虑简洁易读的问题。然而出于种种理由，简洁易读并不容易。主要原因就是易读和其他特性之间往往冲突。例如，库函数越细，就越容易重用，然而使用上就越罗嗦，而且实现分散，不易阅读。为了使得阅读流畅，因此允许对象重载算符，这又引入了算符优先级不定性问题。通常来说，一个语言的设计，总是基于某个特定想法，试图解决某类问题。因此在冲突的目标间，需要做出抉择，例如python之禅。

语言自身产生不易阅读叫做无可奈何，然而人为的编写不易阅读的代码，而且从未意识到这样做的错误，这就属于不思进取了。

参考：

1.http://www.blogjava.net/dreamstone/archive/2007/08/09/134986.html

2.http://imlsb.blogbus.com/logs/97126472.html