2.1 命令范式——一切行动听指挥

第二课伊始，冒号开门见山：“首先介绍一下最原始也是我们最熟悉的编程范式：命令式编程（imperative programming）。用命令式编写的程序由命令序列组成，即一系列祈使句：‘先做这，再做那’，强调‘怎么做’。更学术点说，命令式编程是电脑——准确地讲，是冯•诺伊曼机（von Neumann machine）——运行机制的抽象，即依序从内存中获取指令和数据然后去执行。从范式的角度看，其世界观是：程序是由若干行动指令组成的有序列表；其方法论是：用变量来储存数据，用语句来执行指令。”

逗号小声嘟囔着：“我们用的编程语言不都是命令式的吗？”

“应该说绝大多数语言是命令式的，但非命令式的语言也是存在的。关于后者，我们稍后再议。” 冒号纠正道，“这也在情理之中。语言的演化是渐进的，大多数语言追根溯源是汇编语言的升级，而作为与机器语言一一对应的汇编语言自然是命令式的，因而这种范式最为传统和普及。”

不料问号竟穷追不舍：“为什么机器语言就一定得是命令式呢？”

“我很欣赏你这种打破砂锅问到底的精神，不过你可以问到底，我却不敢保证能答到底哦。”冒号有些逗趣地说。

问号略带腼腆地笑了。

“从理论上而言，完全可以有非命令式的机器语言存在，前提是计算机采用了特殊的硬件实现，比如非冯•诺伊曼结构的数据流机（dataflow machine）和归约机（reduction machine）。但这类计算机并未流行于市，相应的机器语言自然罕见了^[1]。”冒号还是给出了理由。

引号问：“命令式编程与人们常说的过程式编程是一回事吗？”

“严格说来，过程式编程（procedural programming）是指引入了过程（procedure）、函数（function）或子程序（subroutine/subprogram）的命令式编程。但由于现代的命令式语言均具备此特征，故二者往往不加区分。”冒号回应道。

句号认为：“由于常用的语言基本上都是命令式的，其思想也与计算机的运行机制相符，一切对我们来说，似乎都是自然而然的事。”

“单纯的命令式思想的确很朴素，毋庸赘述。” 冒号承认，“但有必要提一下结构化编程（structured programming或简称SP），它是在过程式编程的基础上发展起来的。其本质是一种编程原则，提倡代码应具有清晰的逻辑结构，以保证程序易于读写、测试、维护和优化。可别小瞧它，在上世纪六十年代首次爆发的软件危机中，它曾起着中流砥柱的作用，就像后来的OOP一样。Pascal正是遵循结构化编程原则而设计的一种教学语言，当年也是风光无限。为直观起见，我们用图来表现程序的结构化特征——”

图2-1. 非严格的结构化程序框图

“这是一个流程图（flowchart），或称程序框图，它描述了一个简单程序：用户从标准输入中键入算术表达式，程序打印出结果，如此循环往复，直到用户输入字符‘q’为止。”冒号解释道，“若以纯粹的结构化编程的标准来衡量，该流程图并未达标。”

叹号有些惊讶：“这个图不是再清晰不过了吗？”

“根据结构化定理（structured program theorem）^[2]，任何程序都可用顺序（concatenation）、选择（selection）和循环（repetition）等三种基本控制结构来表示。”冒号画了几幅图——

图2-2. 三种基本控制结构：顺序、选择和循环

冒号指点着黑板：“结构化编程就是在三种基本结构的基础上进行嵌套组合。如果将每个基本结构看作基本电器元件，编程就是将这些元件组装成复杂的电路。请注意，所有基本元件都满足‘单入口、单出口’（single entry, single exit，简称SESE）的原则，这使得电路井井有条，不会串线缠绕。”

引号已经看出：“上面的流程图无法用基本结构来组合，所以不是标准的结构化程序。”

冒号提出要求：“你能改造一下吗？”

引号走上讲台，在前图的基础上作了些许调整——

图2-3. 严格的结构化程序框图

“嗯，不错。这下流程图可以拆解为基本结构了。”冒号表示认可，“二者的区别在于前者利用了break语句，在循环途中退出，后者通过引入quit标志（flag）保证了循环的完整性。”

逗号的脸上写下一个大大的问号：“难道连break语句都不能用吗？”

“break语句只是在循环体内部的跳转，合理地使用它能简化代码，不致影响整体结构，大可不必拘泥于教条。但goto语句可以跳到程序过程中的任一点，造成静态程序（static program）与动态进程（dynamic process）之间的差异，影响程序可读性，是要竭力避免的^[3]。”冒号如是说道，“结构化编程的思想包括两方面。在微观上，主张循规守矩，采用顺序、选择和循环三种逻辑结构，摒弃或限制goto语句^[4]，以避免杂乱无章的代码。在宏观上，主张分而治之（divide and conquer），采用‘自顶向下（top-down）’ ^[5] 的设计，通过模块化将一个较为复杂的系统分解为若干相对简单的子系统，每个子系统可以独立地进一步分解，直到容易编码实现为止。这两方面是互为因果、互为保障的——由基本结构拼装而成的系统一定是模块清晰、层次分明的；反之，系统逐步分解到最后，一定会演化成基本结构。”

叹号产生一个想法：“能从程序的流程图上看出结构化编程与非结构化编程之间的区别吗？”

“一个按结构化编程思想设计的流程图，每个模块大小适中、模块之间关系简明、模块内部线路清晰，单从视觉上就会给人一种美感。相反，如果采用非结构化的设计，流程图往往结构如杂草般松散紊乱、脉络如迷宫般错综复杂、箭头如线头般剪不断理还乱，情节严重的会导致读者头晕目眩乃至抓狂吐血。”冒号极尽夸张之能事。

众人掩口失声。