与其说阅读代码如同读书,不如说如读棋谱
从小阅读计算机编程书籍,
大师们就教育我,
写代码如同写书,
代码是写给人看的,
不是写给机器看的,
所以一定要保证有优良的可读性。
具体的来说就是要做到:
遵守命名规范;
清晰的注释;
最大限度的代码复用。
最好呢,
还有要有完善的文档。
但是,书与程序还有有些不同。
不同的地方在于程序是非空间线性结构。
对于书来讲,
我无论从哪开始翻起,内容都是连续的。
尽管对于一些情节紧凑的小说来讲,
可能从中间开始看,仍然不明所以,
但不影响叙事的线性顺序。
从物理空间的角度看,作者一定是希望读者从上到下,从左到右,从前一页到后一页的顺序来阅读。
而代码不是这样子。
假如我们将一个系统的代码全部打印出来。
连怎么排序都是个问题。
最简单粗放的方式就是按照文件名排列(排序A)。
如果我们按照读书的方式来阅读排序A的结果,
除了超人之外很难能读懂这个系统到底要做什么。
(可以设想下排在前几本的程序会是什么,按这个顺序读代码会是一场灾难)
对于书来讲,最开始一定会是目录和前言。
那我们作一个代码文件的或者函数的目录,并且索引出来。
然后写一个介绍系统功能的前言(排序A改)。
这样可以通过类似于翻新华字典的方式,
来阅读我们的代码。
但我们还是不知道该从何读起。(先找到MAIN()是个明智的做法,但有些时候并没有Main)
一个故事,一定有一个开头,
一个代码,一定有一个入口。
代码的内容的组织方式与故事不同。
代码在物理空间上不是线性的,
而是在时间上线性。
从代码的入口开始,可能下一行的内容要跳到别的代码里,
然后再跳进另一本代码里,
然后出现了一个分支,
再次进入另一本代码
。。。。。。。。
终于在翻了大半本书之后,
跳回了第一页。
然后下一行,
再次跳遍了大半本书。
内容之间只有前后,
没有绝对的下一页一定和这一页相关,
甚至下一行与这一行的相关。
其实,如果看过棋谱的话,就会知道,
代码的这种特性,
与棋谱很像。
棋谱,
有两种记法。
一种是按照着棋的顺序,以纯文字描述。
如象棋棋谱中的 马五平七,车三进四。
一种是绘成图,然后每一着上写着步数。
读者自行按照图中的数字脑补在不同时点棋盘上的样子。
当然,代码是无法如同第二种技法那样具象化的。
所以,阅读代码的最好的方式并不是按照文件和上下文的物理顺序来读,
而是按照时间顺序来组织。
以后可以做个工具以静态分析的方式将程序的调用顺序列出来,
以达到debug单步执行的效果。
《关于阅读代码》有2个想法