原文链接：Functional Programming For The Rest of Us
原文作者：Vyacheslav Akhmechet
翻译：lihaitao (电邮: lihaitao在gmail.com)
校对：刘凯清

程序员拖沓成性，每天到了办公室后，泡咖啡，检查邮箱，阅读 RSS feed，到技术站点查阅最新的文章，在编程论坛的相关版面浏览公共讨论，并一次次地刷新以免漏掉一条信息。然后是午饭，回来后盯了IDE没几分钟，就再次检查邮箱，倒咖啡。最后在不知不觉中，结束了一天。

不平凡的事是每隔一段时间会跳出一些很有挑战性的文章。如果没错，这些天你至少发现了一篇这类文章——很难快速通读它们，于是就将之束之高阁，直到突然你发现自己已经有了一个长长的链接列表和一个装满了PDF文件的目录，然后你梦想着到一个人迹罕至的森林里的小木屋苦读一年以期赶上，要是每天清晨你沿着那里的林中小溪散步时会有人带来食物和带走垃圾就更好了。

虽然我对你的列表一无所知，但我的列表却是一大堆关于函数式编程的文章。而这些基本上是最难阅读的了。它们用枯燥的学院派语言写成，即使“在华尔街行业浸淫十年的专家（veterans）”也不能理解函数式编程（也写作FP）都在探讨些什么。如果你去问花旗集团（Citi Group）或德意志银行（Deutsche Bank）的项目经理[1]，为什么选择了 JMS 而不 Erlang，他们可能回答不能在产业级的应用中使用学院派语言。问题是，一些最为复杂的，有着最严格需求的系统却是用函数式编程元素写成。有些说法不能让人信服。

的确，关于函数式编程的文章和论文难于理解，但他们本来不必这么晦涩。这一知识隔阂的形成完全是历史原因。函数式编程的概念本身并不困难。这篇文章可以作为“简易的函数式编程导引”。是一座从我们命令式（imperative）的思维模式到函数式编程的桥梁。去取杯咖啡回来继续读下去吧。可能你的同事很快就会开始取笑你对函数式编程发表的观点了。

那么什么是函数式编程呢？它怎么产生？它可以被掌握吗（Is it edible)？如果它真如其倡导者所言，为什么没有在行业中得到更广泛的使用？为什么好像只有那些拿着博士学位的人才使用它？最要紧的是，为什么它就 TMD 这么难学？这些 closure, continuation, currying，惰性求值和无副作用等等究竟是些什么东西？没有大学参与的项目怎么使用它？为什么它看上去这么诡异于和我们命令式思想友好，圣洁和亲近的一切的一切？我们将于不久扫清这些疑问。首先让我来解释形成实际生活和学界文章之间巨大隔阂的缘起，简单得像一次公园的散步。

信步游园

启动时间机器，我们散步在两千多年以前的一个被遗忘了太久的春季明媚的日子，那是公元前380年。雅典城墙外的橄榄树树荫里，柏拉图和一个英俊的奴隶小男孩朝着学院走去。“天气真好”，“饮食不错”，然后话题开始转向哲思。

“瞧那两个学生，”为了使问题更容易理解，柏拉图仔细地挑选着用词，“你认为谁更高呢？”
小男孩看着那两个人站着的水漕说，“他们差不多一样高”。
柏拉图说：“你的差不多一样是什么意思？”。“我在这里看他们是一样高的，不过我肯定如果走近些就会看出他们高度的差别。”
柏拉图笑了，他正把这个孩子带到正确的方向。“那么你是说，我们这个世界没有完全的等同了？”
小男孩想了一会儿回答，“对，我不这样认为，任何事物总有一些区别，即使我们看不到它。”
这句话非常到位！“那么如果这世上没有完全的相等，你又是如何理解‘完全’相等这个概念的呢？”
小男孩迷惑得说：“我不知道。”最初尝试着理解数学的本源（nature）时也会产生这种疑惑。

柏拉图暗示这个世上的万物都只是一个对完美的近似。他还认识到我们即使没有接触到完美但依然可以理解这一概念。所以他得出结论，完美的数学形式只能存在于另一个世界，我们通过和那个世界的某种联系在一定程度上知晓他们。很明显我们不能看到完美的圆，但我们可以理解什么是完美的圆并用数学公式将它表达出来。那么，什么是数学？为什么宇宙可以用数学定理描述？数学可以描述宇宙中的所有现象吗？[2]

数学哲学是一个很复杂的课题。像大多数哲学学科一样它更倾向于提出问题而不是给出解答。这些意见中很多都循回绕转于一个事实，即数学实际上是一个谜语：我们设置了一系列基本的不冲突的原理和一些可以施加于这些原理的操作规则，然后我们就能堆砌这些规则以形成更复杂的规则。数学家把这种方法叫做“形式系统”或“演算”。如果愿意，我们可以很快写出一个关于 Tetris（译者注：一种通常被称为俄罗斯方块的游戏）的形式系统。实际上，工作中的 Tetris 实现就是一个形式系统，只是被指定使用了个不常见的表现形式。

人马座的那个生物文明也许不能理解我们的 Tetris 和圆的范式，因为可能他们唯一的感知输入是气味香橙的橘子。他们也许永远不会发现 Tetris 范式，但很可能会有一个圆的范式。我们也可能将无法阅读它，因为我们的嗅觉没有那么复杂，可是一旦我们理解(pass)了那一范式的表示形式（通过这种传感器和标准解码技术来理解这种语言），其底层的概念就可被任何智能文明所理解。

有趣的是如果从来没有智能文明存在，Tetris 和圆的范式仍然严密合理，只是没有人注定将会发现他们。如果产生了一种智能文明，他就会发现一些形式系统来帮助描述宇宙的规律。但他还是不大可能发现 Tetris 因为宇宙中再没有和它相似的事物。在现实世界中这类无用的形式系统或迷题的例子数不胜数，Tetris 只是其中的一个典型。我们甚至不能确定自然数是否是对客观世界的完整近似，至少我们可以简单的想像一个很大的数它不能用宇宙中任何东西描述，因为它以近乎无穷。

历史一瞥[3]

再次启动时间机器，这一次的旅行近了很多，我们回到 1930 年代。大萧条正在蹂躏着那个或新或就的时代。空前的经济下挫影响着几乎所有阶层的家庭生活，只有少数人还能够保持着饥谨危机前的安逸。一些人就如此幸运地位列其中，我们关心的是普林斯顿大学的数学家们。

采用了歌特式风格设计建造的新办公室给普林斯顿罩上天堂般的幸福光环，来自世界各地的逻辑学家被邀请到普林斯顿建设一个新的学部。虽然彼时的美国民众已难能弄到一餐的面包，普林斯顿的条件则是可以在高高的穹顶下，精致雕凿的木质墙饰边上整日的品茶讨论或款款慢步于楼外的林荫之中。

阿隆左·丘奇就是一个在这种近于奢侈的环境中生活着的数学家。他在普林斯顿获得本科学位后被邀留在研究生院继续攻读。阿隆左认为那里的建筑实属浮华，所以他很少一边喝茶一边与人讨论数学，他也不喜欢到林中散步。阿隆左是一个孤独者：因为只有一个人时他才能以最高的效率工作。虽然如此，他仍与一些普林斯顿人保持的定期的联系，其中包括阿兰·图灵，约翰·冯·诺依曼，和 kurt Grodel。

这四个人都对形式系统很感兴趣，而不太留意现实世界，以便致力于解决抽象的数学难题。他们的难题有些共同之处：都是探索关于计算的问题。如果我们有了无限计算能力的机器，哪些问题可以被解决？我们可以使他们自动地得以解决吗？是否还是有些问题无法解决，为什么？不同设计的各种机器是否具有相同的计算能力？

通过和其它人的合作，阿隆左·丘奇提出了一个被称为 lambda 演算的形式系统。这个系统本质上是一种虚拟的机器的编程语言，他的基础是一些以函数为参数和返回值的函数。函数用希腊字母 lambda 标识，这个形式系统因此得名[4]。利用这一形式系统，阿隆左就可以对上述诸多问题推理并给出结论性的答案。

独立于阿隆左，阿兰·图灵也在进行着相似的工作，他提出了一个不同的形式系统（现在被称为图灵机），并使用这一系统独立得给出了和阿隆左相似的结论。后来被证明图灵机和 lambda 演算能力等同。

我们的故事本可以到此结束，我会就此歇笔，而你也将浏览到下一个页面，如果第二次世界大战没有在那时打响。整个世界笼罩在战争的火光和硝烟之中，美国陆军和海军前所未有的大量使用炮弹，为了改进炮弹的精确度，部队组织了大批的科学家持续地计算微分方程以解出弹道发射轨迹。渐渐意识到这个任务用人力手工完成太耗精力后，人们开始着手开发各种设备来攻克这个难关。第一个解出了弹道轨迹的机器是 IBM 制造的 Mark I —— 它重达5吨，有75万个组件，每秒可以完成三次操作。

竞争当然没有就此结束，1949年，EDVAC（Electronic Discrete Variable Automatic Computer，爱达瓦克）被推出并获得了极大的成功。这是对冯·诺依曼架构的第一个实践实例，实际上也是图灵机的第一个现实实现。那一年好运与阿隆左·丘奇无缘。

直到1950年代将尽，一位 MIT 的教授John McCarthy（也是普林斯顿毕业生）对阿隆左·丘奇的工作产生了兴趣。1958年，他公开了表处理语言 Lisp。Lisp 是对阿隆左·丘奇的 lambda 演算的实现但同时它工作在冯·诺依曼计算机上！很多计算机科学家认识到了 Lisp 的表达能力。1973年，MIT人工智能实验室的一组程序员开发了被称为Lisp机器的硬件－阿隆左 lambda 演算的硬件实现！

函数式编程

函数式编程是对阿隆左·丘奇理论的实践应用。但也并非全部 lambda 演算都被应用到了实践中，因为 lambda 演算不是被设计为在物理局限下工作的。因此，象面向对象的编程一样，函数式编程是一系列理念，而不是严格的教条。现在有很多种函数式编程语言，他们中的大多数以不同方式完成不同任务。在本文中我将就最广泛使用的源自函数式编程的思想作一解释，并将用Java语言举例。(的确，你可以用Java写出函数式的程序如果你有显著的受虐倾向）。在下面的小节中，我将会把Java作为一种函数式语言，并对其稍加修改使它成为一种可用的函数式语言。现在开始吧。

lambda 演算被设计用来探询关于计算的问题，所以函数式编程主要处理计算，并惊人地用函数来完成这一过程。函数是函数式编程的基本单位，函数几乎被用于一切，包括最简单的计算，甚至变量都由计算取代。在函数式编程中，变量只是表达式的别名（这样我们就不必把所有东西打在一行里）。变量是不能更改的，所有变量只能被赋值一次。用 Java 的术语来说，这意味着所有单一变量都被声明为 final（或 C++ 的 const）。在函数式编程中没有非 final 的变量。

final int i = 5;
final int j = i + 3;

因为函数式编程中所有变量都是 final 的，所以可以提出这样两个有趣的表述：没有必要总是写出关键字 final，没有必要把变量再称为变量。那么现在我们对Java作出两个修改：在我们的函数式 Java 中所有变量默认都是 final的，我们将变量（variable）称为符号（symbol）。

就此你也许会质疑，用我们新创造的语言还能写出有些复杂度的程序吗？如果每个符号都是不可变更(non-mutalbe)的，那么就无法改变任何状态！其实事实并非完全如此。在阿隆左研究其 lambda 演算时，他并不想将某个状态维护一段时间以期未来对其进行修改。他关注的是对数据的操作（也通常被称为”演算体 caculating stuff”）。既然已被证明lambda演算与图灵机等价，它可以完成所有命令式编程语言能够完成的任务。那么，我们怎么才能做到呢？

答案是函数式程序能保存状态，只是它并非通过变量而是使用函数来保存状态。状态保存在函数的参数中，保存在堆栈上。如果你要保存某个状态一段时间并时不时地对其进行一些修改，可以写个递归函数。举个例子，我们写个函数来翻转 Java 的字符串。记住，我们声明的每个变量默认都是 final 的。[5]

String reverse(String arg) {
if(arg.length == 0) {
return arg;
}
else {
return reverse(arg.substring(1, arg.length)) + arg.substring(0,1);
}}

这个函数很慢因为它不断地调用自己[6]，它还也是个嗜内存魔因为要持续分配对象。不过它的确是在用函数式风格。你可能会问，怎么有人会这样写程序？好的，我这就慢慢讲来：

函数式编程的优点

你可能会认为我根本无法对上面那个畸形的函数给出个合理的解释。我开始学习函数式编程时就是这么认为的。不过我是错了。有很好的理由使用这种风格，当然其中一些属主观因素。例如，函数式程序被认为更容易阅读。因为每个街区的孩子都知道，是否容易理解在旁观者的眼中，所以我将略去这些主观方面的理由。幸运的是，还有很多的客观理由。

单元测试

因为函数式编程的每一个符号都是 final 的，没有函数产生过副作用。因为从未在某个地方修改过值，也没有函数修改过在其作用域之外的量并被其他函数使用（如类成员或全局变量）。这意味着函数求值的结果只是其返回值，而惟一影响其返回值的就是函数的参数。

这是单元测试者的梦中仙境(wet dream)。对被测试程序中的每个函数，你只需在意其参数，而不必考虑函数调用顺序，不用谨慎地设置外部状态。所有要做的就是传递代表了边际情况的参数。如果程序中的每个函数都通过了单元测试，你就对这个软件的质量有了相当的自信。而命令式编程就不能这样乐观了，在 Java 或 C++ 中只检查函数的返回值还不够——我们还必须验证这个函数可能修改了的外部状态。

调试

如果一个函数式程序不如你期望地运行，调试也是轻而易举。因为函数式程序的 bug 不依赖于执行前与其无关的代码路径，你遇到的问题就总是可以再现。在命令式程序中，bug 时隐时现，因为在那里函数的功能依赖与其他函数的副作用，你可能会在和 bug 的产生无关的方向探寻很久，毫无收获。函数式程序就不是这样——如果一个函数的结果是错误的，那么无论之前你还执行过什么，这个函数总是返回相同的错误结果。

一旦你将那个问题再现出来，寻其根源将毫不费力，甚至会让你开心。中断那个程序的执行然后检查堆栈，和命令式编程一样，栈里每一次函数调用的参数都呈现在你眼前。但是在命令式程序中只有这些参数还不够，函数还依赖于成员变量，全局变量和类的状态（这反过来也依赖着这许多情况）。函数式程序里函数只依赖于它的参数，而那些信息就在你注视的目光下！还有，在命令式程序里，只检查一个函数的返回值不能够让你确信这个函数已经正常工作了，你还要去查看那个函数作用域外数十个对象的状态来确认。对函数式程序，你要做的所有事就是查看其返回值！

沿着堆栈检查函数的参数和返回值，只要发现一个不尽合理的结果就进入那个函数然后一步步跟踪下去，重复这一个过程，直到它让你发现了 bug 的生成点。

并行

函数式程序无需任何修改即可并行执行。不用担心死锁和临界区，因为你从未用锁！函数式程序里没有任何数据被同一线程修改两次，更不用说两个不同的线程了。这意味着可以不假思索地简单增加线程而不会引发折磨着并行应用程序的传统问题。

事实既然如此，为什么并不是所有人都在需要高度并行作业的应用中采用函数式程序？嗯，他们正在这样做。爱立信公司设计了一种叫作 Erlang 的函数式语言并将它使用在需要极高抗错性和可扩展性的电信交换机上。还有很多人也发现了 Erlang 的优势并开始使用它。我们谈论的是电信通信控制系统，这与设计华尔街的典型系统相比对可靠性和可升级性要求高了得多。实际上，Erlang 系统并不可靠和易扩展，Java 才是。Erlang 系统只是坚如磐石。

关于并行的故事还没有就此停止，即使你的程序本身就是单线程的，那么函数式程序的编译器仍然可以优化它使其运行于多个CPU上。请看下面这段代码：

String s1 = somewhatLongOperation1();
String s2 = somewhatLongOperation2();
String s3 = concatenate(s1, s2);

在函数编程语言中，编译器会分析代码，辨认出潜在耗时的创建字符串s1和s2的函数，然后并行地运行它们。这在命令式语言中是不可能的，因为在那里，每个函数都有可能修改了函数作用域以外的状态并且其后续的函数又会依赖这些修改。在函数式语言里，自动分析函数并找出适合并行执行的候选函数简单的像自动进行的函数内联化！在这个意义上，函数式风格的程序是“不会过时的技术(future proof)”(即使不喜欢用行业术语，但这回要破例一次)。硬件厂商已经无法让CPU运行得更快了，于是他们增加了处理器核心的速度并因并行而获得了四倍的速度提升。当然他们也顺便忘记提及我们的多花的钱只是用在了解决平行问题的软件上了。一小部分的命令式软件和 100% 的函数式软件都可以直接并行运行于这些机器上。

代码热部署

过去要在 Windows上安装更新，重启计算机是难免的，而且还不只一次，即使是安装了一个新版的媒体播放器。Windows XP 大大改进了这一状态，但仍不理想（我今天工作时运行了Windows Update，现在一个烦人的图标总是显示在托盘里除非我重启一次机器）。Unix系统一直以来以更好的模式运行，安装更新时只需停止系统相关的组件，而不是整个操作系统。即使如此，对一个大规模的服务器应用这还是不能令人满意的。电信系统必须100%的时间运行，因为如果在系统更新时紧急拨号失效，就可能造成生命的损失。华尔街的公司也没有理由必须在周末停止服务以安装更新。

理想的情况是完全不停止系统任何组件来更新相关的代码。在命令式的世界里这是不可能的。考虑运行时上载一个Java类并重载一个新的定义，那么所有这个类的实例都将不可用，因为它们被保存的状态丢失了。我们可以着手写些繁琐的版本控制代码来解决这个问题，然后将这个类的所有实例序列化，再销毁这些实例，继而用这个类新的定义来重新创建这些实例，然后载入先前被序列化的数据并希望载入代码可以恰到地将这些数据移植到新的实例。在此之上，每次更新都要重新手动编写这些用来移植的代码，而且要相当谨慎地防止破坏对象间的相互关系。理论简单，但实践可不容易。

对函数式的程序，所有的状态即传递给函数的参数都被保存在了堆栈上，这使的热部署轻而易举！实际上，所有我们需要做的就是对工作中的代码和新版本的代码做一个差异比较，然后部署新代码。其他的工作将由一个语言工具自动完成！如果你认为这是个科幻故事，请再思考一下。多年来 Erlang工程师一直更新着他们的运转着的系统，而无需中断它。

机器辅助的推理和优化

函数式语言的一个有趣的属性就是他们可以用数学方式推理。因为一种函数式语言只是一个形式系统的实现，所有在纸上完成的运算都可以应用于用这种语言书写的程序。编译器可以用数学理论将转换一段代码转换为等价的但却更高效的代码[7]。多年来关系数据库一直在进行着这类优化。没有理由不能把这一技术应用到常规软件上。

另外，还能使用这些技术来证明部分程序的正确，甚至可能创建工具来分析代码并为单元测试自动生成边界用例！对稳固的系统这种功能没有价值，但如果你要设计心房脉冲产生器 (pace maker)或空中交通控制系统，这种工具就不可或缺。如果你编写的应用程序不是产业的核心任务，这类工具也是你强于竞争对手的杀手锏。

高阶函数

我记得自己在了解了上面列出的种种优点后曾想：“那都是非常好的特性，可是如果我不得不用天生就不健全的语言编程，把一切变量声明为
final 产生的代码将是垃圾一堆。” 这其实是误解。在如Java 这般的命令式语言环境里，将所有变量声明为 final 没有用，但是在函数式语言里不是这样。函数式语言提供了不同的抽象工具它会使你忘记你曾经习惯于修改变量。高阶函数就是这样一种工具。

函数式语言中的函数不同于 Java 或 C 中的函数，而是一个超集——它有着 Java 函数拥有的所有功能，但还有更多。创建函数的方式和 C 中相似:

int add(int i, int j) {
return i + j;
}

这意味着有些东西和同样的 C 代码有区别。现在扩展我们的 Java 编译器使其支持这种记法。当我们输入上述代码后编译器会把它转换成下面的Java代码（别忘了，所有东西都是 final 的）：

class add_function_t {
int add(int i, int j) {
return i + j;
}
}

add_function_t add = new add_function_t();

这里的符号 add 并不是一个函数。这是一个有一个成员函数的很小的类。我们现在可以把 add 作为函数参数放入我们的代码中。还可以把它赋给另一个符号。我们在运行时创建的 add_function_t 的实例如果不再被使用就将会被垃圾回收掉。这些使得函数成为第一级的对象无异于整数或字符串。（作为参数）操作函数的函数被称为高阶函数。别让这个术语吓着你，这和 Java 的 class 操作其它 class（把它们作为参数）没有什么区别。我们本可以把它们称为“高阶类”但没有人注意到这个，因为 Java 背后没有一个强大的学术社区。

那么怎样，何时应该使用高阶函数呢？我很高兴你这样问。如果你不曾考虑类的层次，就可能写出了一整团堆砌的代码块。当你发现其中一些行的代码重复出现，就把他们提取成函数（幸运的是这些依然可以在学校里学到）。如果你发现在那个函数里一些逻辑动作根据情况有变，就把他提取成高阶函数。糊涂了？下面是一个来自我工作的实例：假如我的一些 Java 代码接受一条信息，用多种方式处理它然后转发到其他服务器。

class MessageHandler {
void handleMessage(Message msg) {
// …
msg.setClientCode(”ABCD_123″);
// …

sendMessage(msg);
}

// …

}

现在假设要更改这个系统，现在我们要把信息转发到两个服务器而不是一个。除了客户端的代码一切都像刚才一样——第二个服务器希望这是另一种格式。怎么处理这种情况？我们可以检查信息的目的地并相应修改客户端代码的格式，如下：

class MessageHandler {
void handleMessage(Message msg) {
// …
if(msg.getDestination().equals(”server1″) {
msg.setClientCode(”ABCD_123″);
} else {
msg.setClientCode(”123_ABC”);
}
// …

sendMessage(msg);
}

// …

}

然而这不是可扩展的方法，如果加入了更多的服务器，这个函数将线性增长，更新它会成为我的梦魇。面向对象的方法是把MessageHandler作为基类，在导出类中专业化客户代码操作：

abstract class MessageHandler {
void handleMessage(Message msg) {
// …
msg.setClientCode(getClientCode());
// …

sendMessage(msg);
}

abstract String getClientCode();

// …

}

class MessageHandlerOne extends MessageHandler {
String getClientCode() {
return “ABCD_123″;
}

}

class MessageHandlerTwo extends MessageHandler {
String getClientCode() {
return “123_ABCD”;
}

}

现在就可以对每一个服务器实例化一个适合的类。添加服务器的操作变得容易维护了。但对于这么一个简单的修改仍然要添加大量的代码。为了支持不同的客户代码我们创建了两个新的类型！现在我们用高阶函数完成同样的功能：

class MessageHandler {
void handleMessage(Message msg, Function getClientCode) {
// …
Message msg1 = msg.setClientCode(getClientCode());
// …

sendMessage(msg1);
}

// …

}

String getClientCodeOne() {
return “ABCD_123″;

}

String getClientCodeTwo() {
return “123_ABCD”;

}

MessageHandler handler = new MessageHandler();
handler.handleMessage(someMsg, getClientCodeOne);

没有创建新的类型和新的class层次，只是传入合适的函数作为参数，完成了面向对象方式同样的功能，同时还有一些额外的优点。没有使自己囿于类的层次之中：可以在运行时传入函数并在任何时候以更高的粒度更少的代码修改他们。编译器高效地为我们生成了面向对象的“粘合”代码！除此之外，我们还获得了所有函数式编程的其他好处。当然函数式语言提供的抽象不只这些，高阶函数只是一个开始：

currying

我认识的大多数人都读过“四人帮”的那本设计模式，任何自重的程序员都会告诉你那本书是语言中立的(agnostic)，模式在软件工程中是通用的，和使用的语言无关。这个说法颇为高贵，故而不幸的是，有违现实。

函数式编程极具表达能力。在函数式语言中，语言既已达此高度，设计模式就不再是必需，最终你将设计模式彻底消除而以概念编程。适配器(Adapter)模式就是这样的一个例子。(究竟适配器和 Facade 模式区别在哪里？可能有些人需要在这里再多费些篇章)。一旦语言有了叫作 currying 的技术，这一模式就可以被消除。

currying.

适配器模式最有名的是被应用在 Java 的“默认”抽象单元——class 上。在函数式编程里，模式被应用到函数。模式带有一个接口并将它转换成另一个对他人有用的接口。这有一个适配器模式的例子：

int pow(int i, int j);
int square(int i)
{
return pow(i, 2);
}

上面的代码把一个整数幂运算接口转换成为了一个平方接口。在学术文章里，这个雕虫小技被叫作currying(得名于逻辑学家Haskell
Curry，他曾将相关的数学理论形式化 )。因为在函数式编程中函数（反之如class)被作为参数来回传递，currying 很频繁地被用来把函数调整为更适宜的接口。因为函数的接口是他的参数，使用 currying 可以减少参数的数目(如上例所示)。

函数式语言内建了这一技术。不用手动地创建一个包装了原函数的函数，函数式语言可以为你代劳。同样地，扩展我们的语言，让他支持这个技术：

square = int pow(int i, 2);

这将为我们自动创建出一个有一个参数的函数 square。他把第二个参数设置为 2 再调用函数 pow。这行代码会被编译为如下的 Java 代码：

class square_function_t {
int square(int i) {
return pow(i, 2);
}
}

square_function_t square = new square_function_t();

正如你所见，通过简单地创建一个对原函数的包装，在函数式编程中，这就是 currying —— 快速简易创建包装的捷径。把精力集中在你的业务上，让编译器为你写出必要的代码！什么时候使用 currying？这很简单，任何时候你想要使用适配器模式（包装）时。

惰性求值

惰性（或延迟）求值这一技术可能会变得非常有趣一旦我们采纳了函数式哲学。在讨论并行时已经见过下面的代码片断：

String s1 = somewhatLongOperation1();
String s2 = somewhatLongOperation2();
String s3 = concatenate(s1, s2);

在一个命令式语言中求值顺序是确定的，因为每个函数都有可能会变更或依赖于外部状态，所以就必须有序的执行这些函数：首先是
somewhatLongOperation1，然后 somewhatLongOperation2，最后 concatenate，在函数式语言里就不尽然了。

前面提到只要确保没有函数修改或依赖于全局变量，somewhatLongOperation1 和 somewhatLongOperation2 可以被并行执行。但是如果我们不想同时运行这两个函数，还有必要保证有序的执行他们呢？答案是不。我们只在其他函数依赖于s1和s2时才需要执行这两个函数。我们甚至在concatenate调用之前都不必执行他们——可以把他们的求值延迟到concatenate函数内实际用到他们的位置。如果用一个带有条件分支的函数替换concatenate并且只用了两个参数中的一个，另一个参数就永远没有必要被求值。在 Haskell 语言中，不确保一切都（完全）按顺序执行，因为 Haskell 只在必要时才会对其求值。

惰性求值优点众多，但缺点也不少。我们会在这里讨论它的优点而在下一节中解释其缺点。

优化

惰性求值有客观的优化潜力。惰性编译器看函数式代码就像数学家面对的代数表达式————可以注销一部分而完全不去运行它，重新调整代码段以求更高的效率，甚至重整代码以降低出错，所有确定性优化(guaranteeing optimizations)不会破坏代码。这是严格用形式原语描述程序的巨大优势————代码固守着数学定律并可以数学的方式进行推理。

抽象控制结构

惰性求值提供了更高一级的抽象，它使得不可能的事情得以实现。例如，考虑实现如下的控制结构：

unless(stock.isEuropean()) {
sendToSEC(stock);
}

我们希望只在祖先不是欧洲人时才执行sendToSEC。如何实现 unless？如果没有惰性求值，我们需要某种形式的宏（macro）系统，但
Haskell 这样的语言不需要它。把他实现为一个函数即可：

void unless(boolean condition, List code) {
if(!condition)
code;
}

注意如果条件为真代码将不被执行。我们不能在一个严格（strict）的语言中再现这种求值，因为 unless 调用之前会先对参数进行求值。

无穷(infinite)数据结构

惰性求值允许定义无穷数据结构，对严格语言来说实现这个要复杂的多。考虑一个 Fibonacci 数列，显然我们无法在有限的时间内计算出或在有限的内存里保存一个无穷列表。在严格语言如 Java 中，只能定义一个能返回 Fibonacci 数列中特定成员的 Fibonacci 函数，在 Haskell
中，我们对其进一步抽象并定义一个关于 Fibonacci 数的无穷列表，因为作为一个惰性的语言，只有列表中实际被用到的部分才会被求值。这使得可以抽象出很多问题并从一个更高的层次重新审视他们。（例如，我们可以在一个无穷列表上使用表处理函数）。

缺点

当然从来不存在免费的午餐。惰性求值有很多的缺点，主要就在于，懒。有很多现实世界的问题需要严格求值。例如考虑下例：

System.out.println(”Please enter your name: “);
System.in.readLine();

在惰性求值的语言里，不能保证第一行会在第二行之前执行！那么我们就不能进行输入输出操作，不能有意义地使用本地（native）接口（因为他们相互依赖其副作用必须被有序的调用），从而与整个世界隔离。如果引入允许特定执行顺序的原语又将失去数学地推理代码的诸多好处（为此将葬送函数式编程与其相关的所有优点）。幸运的是，并非丧失了一切，数学家为此探索并开发出了许多技巧来保证在一定函数设置下(function setting)代码以一特定的顺序执行。这样我们就赢得了两个世界。这些技术包括 continuation， monad 和 uniqueness typing
（一致型别）。我只会在本文中解释continuation，把 monad 和 uniqueness typing 留到将来的文章中。有趣的是，除了确保函数求值顺序， continuation 在很多别的情况下也很有用。这点等一会儿就会提到。

Continuations

Continuations 对于程序设计的意义，就像《达芬奇密码》对人类历史的意义：即对人类最大秘密的惊人揭示。也许不是，但他在概念上的突破性至少和揭示了负数的平方根意义等同。

我们在学习函数时，只是学到了一半的事实，因为我们基于一个错误的假定:函数只能将结果返回到它的调用函数。在这个意思上continuation 是广义的函数。函数不必要返回到其调用函数而可以返回到程序的任何地方。我们把”continuation” 作为参数传给一个函数，它指定了这个函数返回的位置。这个描述可能听起来更加复杂。看一下下面的代码：

int i = add(5, 10);
int j = square(i);

函数 add 在其被调用的位置将结果 15 赋给了 i，接下来 i 的值被用来调用 square。注意所有的惰性求值编译器都不能调整这几行代码因为第二行依赖着第一行的成功求值。下面用 continuation 风格又称 CPS (Continuation Programming Style) 来重写这段代码，这里函数 add 会将结果返回到 square 而不是原来的调用函数。

int j = add(5, 10, square);

这个例子中 add 有了另一个参数 —— 一个 add 必须在它求值结束时用其返回值调用的函数。这里 square 是 add 的一个 continuation。这两种情况下，j 都将等于 255。

这就是强制使惰性语言有序地求值两个表达式的第一个技巧。考虑下面这个（熟悉的）IO代码：

System.out.println(”Please enter your name: “);
System.in.readLine();

这两行不相依赖所以编译器会自由的重新调整他们的执行顺序。然而，如果我们用 CPS 来重写这段代码，就会有一个依赖，编译器会因此而强制对这两行代码有序执行！

System.out.println(”Please enter your name: “, System.in.readLine);

这里 println 需要用自己的返回结果作为参数去调用 readLine 并将 readLine 返回值作为自己的返回值。这样就能确保这两行被有序执行而且 readLine 一定被执行（因为整个计算期望最后的结果为结果）。Java 的 println 返回 void 但如果它返回的是一个抽象值（readLine所期待的），我们就解决了这个问题！当然这样的链接函数调用很快就会使代码难以读懂，不过这个可以避免。比如我们可以给语言添加些语法甜点(syntactic sugar)就可以简单的按顺序输入表达式，然后由编译器自动为我们链接这些函数调用。这样就可以如愿地使用期望的求值顺序并保留一切函数式编程的好处（包括数学地对我们程序进行推理的能力）！如果还是有迷惑，记住函数是只有一个成员的类的实例。重写上述代码使得 println 和 readLine 成为类的实例，这样就对一切都清楚了。

如果我在此结束本节，那将仅仅涉及到 continuation 最浅显的应用。用 CPS 重写整个程序，那里所有的函数都增加一个额外的 continuation 参数并把函数结果传给它。也可以通过简单地把函数当作 continuation 函数（总是返回到调用者的函数）的特殊实例来将程序转为 CPS 风格。这种转换很容易被自动化（事实上，许多编译器就是这么做的）。

一旦我们将一个程序转为了CPS，那么很明显每个指令都将有些 continuation, 这是一个该指令在执行结束时会用其执行结果调用的函数，通常的程序中，这是一个它要返回的地址。从上面的例子中随便举个例子，比如 add(5, 10)。在用CPS风格写的程序里，add 的continuation很明显——这是一个 add 在其执行结束时会调用的函数。那么如果在非CPS的程序里，它是什么呢？当然我们可以把程序转为 CPS ，但有这个必要吗？

其实没有必要。仔细看一下我们的 CPS 转换过程。如果尝试为它写一个编译器，然后经过长期的思考后，你意识到这个 CPS 的版本根本不需要栈！没有函数会以传统的意义“返回”，它只是用结果调用了另一个函数。我们无需在调用时将函数参数压栈再于调用结束时弹出栈，而只是简单的把他们保存在一大块内存中，然后使用跳转指令。不再需要原来的参数——他们不会再次被用到，因为没有函数会返回！

所以，用 CPS 风格写成的程序没有堆栈，但每个函数却有一个额外的参数可被调用。不是 CPS 风格的程序没有可以被调用的这个参数，但却有栈。栈中存放着什么？只是参数和一个指向函数返回地址的指针。你看到光了吗？栈中只是放着 continuation 的信息！ 栈中指向返回指令的指针本质上和 CPS 程序里将被调用的函数是等价的。如果你想探究 add(5,10) 的 continuation，只要简单地检查它在堆栈的执行点！

这的确很简单。continuation 和栈上指向返回地址的指针是等价的，只是 continuation 是被显式传递，所以不必和函数被调用点是同一位置。如果还记得 continuation 就是一个函数，并且在我们的语言里，函数被编译为一个类的实例，你就会理解指向栈中返回指令的指针实际就是传递给 continuation 的参数，因为我们的函数（就像一个类的实例）只是一个指针。这意味着给定程序中任意时间和任意位置，你都可以去请求一个当前的 continuation (current continuation)（它就是当前的栈的信息）。

好的，这样我们就知道了什么是 current continuation。他有什么意义？一旦我们得到了当前的 continuation 并将它保存在某处，我们就最终将程序当前的状态保存了下来——及时地冷冻下来。这就像操作系统将其置为休眠状态。一个 continuation 对象里保存了在我们获得它的地方重新启动程序的必要信息。操作系统在每次发生线程间的上下文切换时也是如此。唯一的区别是它保留着全部控制。请求一个continuation 对象（在Scheme里，可以调用 call-with-current-continuation 函数）后，你就会获得一个包括了当前 continuation
的对象——堆栈（或者在CPS情况下则是下一个要调用的函数）。可以把这个对象保存在一个变量（或者是磁盘）里。当你用这 continuation “重启”程序时，就会转回到处你取得这个对象的那个状态。这就象切换回一个被挂起的线程或唤醒休眠着的操作系统，区别是用 continuation，你可以多次地重复这一过程。当操作系统被唤醒时，休眠信息就被销毁了。但如果那些信息没有被销毁，你也就可以一次次地将它唤醒到同一点，就象重返过去一样。有了 continuation 你就有了这个控制力！

Continuation 应该在什么情况下使用呢？通常在尝试模拟一个本质上是无状态的应用时可以简化你的任务。Continuation 很适合在Web应用程序中使用。微软公司的 ASP.NET 技术极尽苦心地模拟状态以便你在开发 Web 应用时少费周折。可如果 C# 支持了continuation，ASP.NET 的复杂度就可以减半——你只需要保存一个 continuation，当用户下次发出 web 请求时重启它即可。对程序员来说，web 应用程序将不再有中断——程序只是简单的从下一行重启！利用 continuation 这一抽象解决问题真是令人难以置信的便利。考虑到越来越多的胖客户端应用程序正在向服务器端转移，将来 continuation 也会变得越来越重要。

模式匹配

模式匹配不是什么新的创新的特性。事实上，它和函数式编程的关系不大。把产生模式匹配归因于函数式编程的唯一的原因是函数式语言一度提供了模式匹配，然而现在的命令式语言还做不到。

让我们用一个例子深入了解一下模式匹配。这是一个Java的Fibonacci函数：

int fib(int n) {
if(n == 0) return 1;
if(n == 1) return 1;

return fib(n - 2) + fib(n - 1);
}

让我们从Java衍生出的语言来支持模式匹配：

int fib(0) {
return 1;
}

int fib(1) {
return 1;
}

int fib(int n) {
return fib(n - 2) + fib(n - 1);

}

两者有什么区别？编译器为我们实现了分支。这有什么大不了？的确没什么。有人注意到很多函数包括了复杂的 swith 语句（尤其是在函数式程序中）所以认为这种抽象形式很好。我们把一个函数定义分离成多个，然后把模式置于参数中（有点象重载）。当这个函数被调用时，编译器使其比较参数和其运行时的定义然后选择其中正确的一个。这一般是通过选择可选的最特定的定义来完成。例如，int fib(int n) 可以以 n 等于 1 被调用，但是实际上 fib(n) 没有被调用，因为 fib(1) 更加特定。

模式匹配通常要比我这个例子复杂，比如，高级模式匹配系统可以让我们这样做：

int f(int n < 10) { ... }
int f(int n) { ... }

模式匹配什么时候适用？情况太多了！每当你有一个嵌套着 if 的复杂的数据结构，这时就可以用模式匹配以更少的代码完成得更好。一个很好的例子闪现在我脑海，这就是所有 Win32 平台都提供了的标准的 WinProc 函数（即使它通常被抽象了）。通常模式匹配系统能检测集合也可以应付简单的值。例如，当传给函数一个数组后，就可以找出所有首元素为 1 第三个元素大于 3 的所有数组。

模式匹配还有一个好处即如果需要增加或修改条件，那么不必对付一个巨大的函数。只需增加或修改适合的定义即可。这消除了“四人帮”（GoF）书中的一大类设计模式。条件越复杂，模式匹配就越有用。一旦习惯了它，你就会担心没有了模式匹配的日子如何打发。

Closures

到此我们已经讨论了纯的函数式语言——实现了lambda演算又不包括与丘奇形式系统矛盾的语言——环境里的特性，可是还有很多在lambda演算框架之外的函数语言的有用特征。虽然一个公理系统的实现可以让我们象数学表达式那样思考程序但它未必是实际可行的。许多语言选择去合并一些函数式的元素而没有严格的坚持函数式的教条。很多象这样的语言（如Common Lisp）不要求变量是 final 的——可以即处对其修改。他们还不要求函数只依赖于其参数——允许函数访问外部状态。但这些语言也的确包含着函数式的特征——如高阶函数，在非纯粹的函数式语言里传递函数作为参数和限制在 lambda 演算系统中的作法有些不同，它需要一种常被称为词法（lexical）closure 的有趣特性。下面我给出几个例子。记住，这里变量不再是final的，函数可以引用其作用域外的变量：

Function makePowerFn(int power) {
int powerFn(int base) {
return pow(base, power);
}
return powerFn;
}

Function square = makePowerFn(2);
square(3); // returns 9

函数 make-power-fn 返回了一个函数，它有一个参数，并对这个参数进行一定阶的幂运算。如果对 square(3) 求值会有什么结果？变量 power 不在 powerFn 的作用域中，因为 makePowerFn 已经返回它的栈桢而不复存在。那么square如何工作？一定是这个语言以某种方式将power的值保存了起来以便 square 使用。如果我们再新建一个函数cube，用来计算参数的立方又会怎样？运行环境必须存储两个power的拷贝，每个我们用 make-power-fn 生成的函数都用一个拷贝。保存这些值的现象就被称为 closure。 closure 不只保存宿主函数的参数。例如，closure可能会是这样：

Function makeIncrementer() {
int n = 0;

int increment() {
return ++n;
}
}

Function inc1 = makeIncrementer();
Function inc2 = makeIncrementer();

inc1(); // returns 1;
inc1(); // returns 2;
inc1(); // returns 3;
inc2(); // returns 1;
inc2(); // returns 2;
inc2(); // returns 3;

运行时已保存了n，所以递增器可以访问它，而且运行时为每个递增器都保存了一个 n 的拷贝，即使这些拷贝本应在 makeIncrementer
返回时消失。这些代码被如何编译？closure 在底层是如何工作的？很幸运，我们可以去幕后看看。

一点常识会很有帮助，首先会注意到的是局部变量的生命期不再由简单的作用域限定而是不确定的。那么显然可以由此得出结论它们不再被保存在栈上——反之必须被保存在堆上[8]。这样一来，closure 的实现就象我们前面讨论的函数一样了，只是它还有一个指向周围变量的引用。

class some_function_t {
SymbolTable parentScope;

// …

}

当一个 closure 引用了一个不在其作用域的变量时，它会在其祖先作用域中查找这个引用。就是这样！Closure 将函数式和面向对象的世界紧密结合。当你创建了一个包含了一些状态的类并把它传到别处时，考虑一下 closure。Closure 就是这样在取出作用域中的变量的同时创建“成员变量”，所以你不必亲自去做这些！

下一步的计划？

关于函数式编程，本文作了浅显地讨论。有时候一次粗浅的射猎可能会进展为重大的收获与我也受益匪浅。将来我还计划写写 category 理论，monad，函数式数据结构，函数式语言中的类型(type)体系，函数式并发，函数式数据库等等还有很多。如果我得以（在学习的过程中）写出了上述诸多主题中的一半，我的生命就会完整了。还有，Google 是我们的朋友。

评论？

如果你有任何问题，意见或建议，请发到邮箱 coffee…@gmail.com。很高兴收到你的反馈

===========================

[1] 我在2005年找工作时常常提出这个问题，当时我得到的是数量可观的一脸茫然。想像一下，这些人至少每人会得到30万美元，如果他们理解了他们可以得到的大部分工具。

[2] 这像是个悖论。物理学家和数学家被迫确认他们还不完全清楚是否宇宙万物遵循着可以被数学描述的规则。

[3] 我一直厌恶提供了一堆枯燥的日期，人名和地点的纪年式历史课。对我而言，历史是改变了这个世界的人的生活，是他们行为之后的个人动机，是他们得以影响亿万生灵的体制。所以这个关于历史的小节注定无法完整，只讨论了于此关系及其密切的人物与事件。

[4] 我在学习函数式编程的时候，很不喜欢术语 lambda，因为我没有真正理解它的意义。在这个环境里，lambda 是一个函数，那个希腊字母只是方便书写的数学记法。每当你听到 lambda 时，只要在脑中把它翻译成函数即可。

[5] 有趣的是 Java 的字符串是不可变更的，探讨这一离经叛道的设计的原因也非常有趣，不过在这里会分散我们对原目标的注意力

[6] 大多数函数式编程语言的编译器能通过将递归尽可能转为迭代来进行优化，这被称为尾递归。

[7] 相反未必成立，虽然有时可以证明两端代码等价，但这不是所有情况下都成立。

[8] 这实际上不比存储在栈上慢，因为一旦引入了垃圾回收器，内存分配就成为了一个O(1)的操作。

总 论

本规范既是一个开发规范，也是一个脚本语言参考，本规范并不是一个一成不变的必须严格遵守的条文，特殊情况下要灵活运用，做一定的变通。但是，请大家千万不要随意更改规范。如果有任何问题，请及时与我联系，我会及时更改本规范的相关代码样例和文档。

基 本 要 求

1. 在网站根目录中开设images common temp 三个子目录，根据需要再开设media 子目录，images目录中放不同栏目的页面都要用到的公共图片，例如公司的标志、banner 条、菜单、按钮等等；common 子目录中放css、js,、php、include 等公共文件；temp 子目录放客户提供的各种文字图片等等原始资料；media 子目录中放flash, avi, quick time 等多媒体文件 。

2. 在根目录中原则上应该按照首页的栏目结构，给每一个栏目开设一个目录，根据需要在每一个栏目的目录中开设一个images 和media 的子目录用以放置此栏目专有的图片和多媒体文件，如果这个栏目的内容特别多，又分出很多下级栏目，可以相应的再开设其他目录。

3. temp 目录中的文件往往会比较多，建议以时间为名称开设目录，将客户陆续提供的资料归类整理。

4. 除非有特殊情况，目录、文件的名称全部用小写英文字母、数字、下划线的组合，其中不得包含汉字、空格和特殊字符；目录的命名请尽量以英文为指导，不到万不得已不要以拼音作为目录名称，经验证明，用拼音命名的目录往往连一个月后的自己都看不懂，

脚 本 编 写

我们应该有一个脚本整体风格一致的概念，意思是一个月后和一个月前的你写的脚本风格保持一致，以及同一个工作组中不同的开发人员编写的脚本风格保持一致，因为我们不可能永远孤立的开发，你随时都有可能和三个月前的自己合作（你的客户要求改版），也经常要和工作室中不同的同事共同开发一个项目，还有可能被要求修改已经离职人员开发的脚本，当然你自己也有可能会扔下一个项目给后来的同事。

1. Html 文件的通用模板：

<html>
<!--
Generator: Sub Design Studio ( http://www.eastline.net.cn)
Creation Data: 2000-8-1
Original Author: eastline
-->
<head>
<title> 文档标题 </title>
<meta http-equiv="content-type" content="text/html; charset=gb2312">
<meta name="author" content="eastline">

其他meta 标 记
<link rel="stylesheet" type="text/css" href="style/style.css">

样式表定义

客户端javascript 函数定义及初始化操作
</head>
<body bgcolor="#ffffff">
… …
</body>

补充：
为了保证网站能够与下一代的web 语言xml 标准兼容，所有的HTML 标签的属性都要用单引号或者双引号括起，即我们应该写 <a href=”url”> 而不 是 <a href=url>.

2. 允许全文检索的页面，为了使Internet 上的搜索引擎能够有效检索，在频道的首页的html的<head></head>之间应该加入Keywords 和Description 元标记，例如 ：

<meta name=”keywords” content=”东方新干线，汽车，买车”>
<meta name=”description” content=”东方新干劲线，全球中文汽车信息第一站”>

3. CSS 文件的格式样例代码 ：

<style type="text/css">
<!—
p { text-indent: 2em; }
body { font-family: "宋体"; font-size: 9pt; color: #000000; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px}
table { font-family: "宋体"; font-size: 9pt; line-height: 20px; color: #000000}
a:link { font-size: 9pt; color: #FFFFFF; text-decoration: none}
a:visited { font-size: 9pt; color: #99FFFF; text-decoration: none}
a:hover { font-size: 9pt; color: #FF9900; text-decoration: none}
a:active { font-size: 9pt; color: #FF9900; text-decoration: none}
a.1:link { font-size: 9pt; color: #3366cc; text-decoration: none}
a.1:visited { font-size: 9pt; color: #3366cc; text-decoration: none}
a.1:hover { font-size: 9pt; color: #FF9900; text-decoration: none}
a.1:active { font-size: 9pt; color: #FF9922; text-decoration: none}
.blue { font-family: "宋体"; font-size: 10.5pt; line-height: 20px; color: #0099FF; letter-spacing: 5em}
-->
</style>

这里尤其要注意的是a:link a:visited a:hover a:actived 的排列顺序一定要严格照上面的样例代码，否则或多或少会出问题。另外我们规定重定义的最先，伪类其次，自定义最后，便于自己和他人阅读！

为了保证不同浏览器上字号保持一致，字号建议用点数pt和像素px来定义，pt一般使用中文宋体的9pt和11pt，px一般使用中文宋体12px 和14.7px 这是经过优化的字号，黑体字或者宋体字加粗时，一般选用11pt和14.7px 的字号比较合适。

在写 <table> 互相嵌套时，严格按照的规范，对于单独的一个<table>来说，<table><tr>对齐，<td> 缩进两个半角空格，<td> 中如果还有嵌套的表格，<table>也缩进两个半角空格，如果<td>中没有任何嵌套的表格，</td> 结束标记应该与 <td> 处于同一行，不要换行，

如我们注意在源代码中不应有这样的代码：

<td><img src=”../images/sample.gif”>
</td>

而应该是这样的：
<td><img src=”../images/sample.gif”></td>

这是因为浏览器认为换行相当于一个半角空格，以上不规范的写法相当于无意中增加一个半角空格，如果确实有必要增加一个半角空格，也应该这样写：

<td><img src=”../images/sample.gif”> </td>

属于同一个级别 的 <table> 一定是左首对齐的，另外不允许没有任何内容的空的单元格存在，高度大于等于12px 的单元格应该 在 <td> 和 </td> 之间写一 个 如果高度小于12px, 则应该 在 <td> 和 </td> 之间插入一个1*1 大小的透明的gif 图片，这是因为某些浏览器认为空单元格非法而不会予以解释。如果代码顺序较乱，在DW3中可以通过command->apply souce formatting进行重新整理！

5. Width 和height 的写法也有统一的规范，一般情况下只有一列的表格，width 写在<table> 的标签内，只有一行的表格，height 写在 <table> 的标签内，多行多列的表格，width 和height 写在第一行或者第一列的 <td> 标签内。总之遵循一条原则：不出现多于一个的控制同一个单元格大小的height 和width, 保证任何一个width 和height 都是有效的，也就是你改动代码中任何一个width 和height 的数值，都应该在浏览器中看到变化。做到这一条不容易，需要较长时间的练习和思考。

一 般 原 则

1. 在排布表格之前，请大家一定要好好思考一个最佳的方案，表格的嵌套尽量控制在三层以内，并且应该尽量避免 <colspan> <rowspan> 两个标记，经验表明，这两个标记会带来许多麻烦。

2. 一个网页要尽量避免用整个一张大表格，所有的内容都嵌套在这个大表格之内，因为浏览器在解释页面的元素时，是以表格为单位逐一显示，如果一张网页是嵌套在一个大表格之内，那么很可能造成的后果就是，当浏览者敲入网址，他要先面对一片空白很长时间，然后所有的网页内容同时出现。如果必须这样做，请使用 <tbody>标记，以便能够使这个大表格分块显示。

3. 排版中我们经常会遇到需要进行首行缩进的处理，不要使用 或者全角空格来达到效果，规范的做法是在样式表中定义 p { text-indent: 2em; } 然后给每一段加上 <p> 标记，注意，一般情况下，请不要省略 </p> 结束标记 。

4. 原则上，我们禁止用 <img width=? height=?> 来人为干预图片显示的尺寸，而且建议 <img> 标签中不要带上width 和height 两个属性，这是因为制作过程中，图片往往需要反复的修改，这样可以避免人为干预图片显示的尺寸，尽可能的发挥浏览器自身的功能；但是这样的一个副作用是当网页还未加载图片时，不会留出图片的站位大小，可能会造成网页在加载过程中抖动（如果图片是插在一个固定大小的表格里的，不会有这个现象），尤其是当图片的尺寸较大时，这种现象会很明显，所以当预料到这种会明显导致网页抖动的情况会发生时，请大家务必在最后给 <img>附上 width 和 height 属性。

5. 为了最大程度的发挥浏览器自动排版的功能，在一段完整的文字中请尽量不要使用<br> 来人工干预分段。

6. 不同语种的文字之间应该有一个半角空格，但避头的符号之前和避尾的符号之后除外汉字之间的标点要用全角标点，英文字母和数字周围的括号应该使用半角括号。

7. 所有的字号都应该用样式表来实现，禁止在页面中出现 <font size=?> 标记。

8. 请不要在网页中连续出现多于一个 的 也尽量少使用全角空格（英文字符集下，全角空格会变成乱码），空白应该尽量使用 text-indent, padding, margin, hspace, vspace 以及透明的gif 图片来实现。

9. 中英文混排时，我们尽可能的将英文和数字定义为verdana 和arial 两种字体。

10. 行距建议用百分比来定义，常用的两个行距的值是line-height:120%/150%.

11. 网站中的路径全部采用相对路径，一般链接到某一目录下的缺省文件的链接路径不必写全名，如我们不必这样：<a href=”aboutus/index.htm”> 而应该这样：<a href=”aboutus/”>

12、嵌入图形文本的使用较大的字体，建议不要在图形中包括文本。

13、“网页大小”定义为网页的所有文件大小的总和，包括HTML文件和所有的嵌入的对象。用户喜欢快的而不是新奇的站点。对于解调器用户，网页大小保持在34K以下为合适。

文 件 命 名 原 则

1. 每一个目录中应该包含一个缺省的html 文件，文件名统一用index.htm

2． 件名称统一用小写的英文字母、数字和下划线的组合。

3. 命名原则的指导思想一是使得你自己和工作组的每一个成员能够方便的理解每一个文件的意义，二是当我们在文件夹中使用“按名称排例”的命令时，同一种大类的文件能够排列在一起，以便我们查找、修改、替换、计算负载量等等操作 。

4. 下面以“新闻”（包含“国内新闻”和“国际新闻”）这个栏目来说明html 文件的命名原则 ：

☆ 在根目录下开设news目 录

☆ 第一条缺省新闻取名index.htm

☆ 所有属于“国内新闻”的新闻依次取名为：china_1.htm, china_2.htm, …

☆ 所有属于“国际新闻”的新闻依次取名为：internation_1.htm, internation _2.htm, …

☆ 如果文件的数量是两位数，请将前九个文件命名为：china_01.htm, china_02.htm 以保证所有的文件能够在文件夹中正确排序。

5. 图片的命名原则遵循以下几条规范 ：

☆ 名称分为头尾两两部分，用下划线隔开。

☆ 头部分表示此图片的大类性质，例如广告、标志、菜单、按钮等等 。

☆ 一般来说:

放置在页面顶部的广告、装饰图案等长方形的图片我们取名：banner
标志性的图片我们取名为：logo
在页面上位置不固定并且带有链接的小图片我们取名为button
在页面上某一个位置连续出现，性质相同的链接栏目的图片我们取名：menu
装饰用的照片我们取名：pic
不带链接表示标题的图片我们取名：title
依照此原则类推。

☆ 尾部分用来表示图片的具体含义。

☆ 下面是几个样例，大家应该能够一眼看明白图片的意义：
banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.gif title_news.gif logo_police.gif logo_national.gif pic_people.jpg pic_hill.jpg.

目录建立的原则：以最少的层次提供最清晰简便的访问结构。

根目录。
根目录指DNS域名服务器指向的索引文件的存放目录。
服务器的ftp上传目录默认为html

根目录文件
根目录只允许存放index.html和main.html文件，以及其他必须的系统文件。

每个语言版本存放于独立的目录。已有版本语言设置为：
简体中文 \gb
繁体中文 \big5
英 语 \en
日 语 \jp

每个主要功能(主菜单)建立一个相应的独立目录。

根目录下的images为存放公用图片目录，每个目录下私有图片存放于各自独立images目录.
例如：\menu1\images
\menu2\images

所有的js文件存放在根目录下统一目录\script
所有的CSS文件存放在根目录下的style目录
所有的CGI程序存放在根目录并列目录\cgi_bin目录
head区是指首页HTML代码的<head>和</head>之间的内容。
必须加入的标签

1.公司版权注释<!--- The site is designed by Maketown,Inc 06/2000 --->

2.网页显示字符集
简体中文：<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=gb2312">
繁体中文：<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=BIG5">
英 语：<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

3.网页制作者信息
<META name="author" content="webmaster@maketown.com">

4.网站简介
<META NAME="DESCRIPTION" CONTENT="xxxxxxxxxxxxxxxxxxxxxxxxxx">

5.搜索关键字
<META NAME="keywords" CONTENT="xxxx,xxxx,xxx,xxxxx,xxxx,">

6.网页的css规范
<LINK href="style/style.css" rel="stylesheet" type="text/css">
(参见目录及命名规范)

7.网页标题
<title>xxxxxxxxxxxxxxxxxx</title>

.可以选择加入的标签

1.设定网页的到期时间。一旦网页过期，必须到服务器上重新调阅。
<META HTTP-EQUIV="expires" CONTENT="Wed, 26 Feb 1997 08:21:57 GMT">

2.禁止浏览器从本地机的缓存中调阅页面内容。
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

3.用来防止别人在框架里调用你的页面。
<META HTTP-EQUIV="Window-target" CONTENT="_top">

4.自动跳转。
<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://www.yahoo.com">
5指时间停留5秒。

5.网页搜索机器人向导.用来告诉搜索机器人哪些页面需要索引，哪些页面不需要索引。
<META NAME="robots" CONTENT="none">
CONTENT的参数有all,none,index,noindex,follow,nofollow。默认是all。

6.收藏夹图标
<link rel = "Shortcut Icon" href="favicon.ico">

所有的javascript的调用尽量采取外部调用.
<SCRIPT LANGUAGE="javascript" SRC="script/xxxxx.js"></SCRIPT>

附<body>标签：
<body>标签不属于head区，这里强调一下，为了保证浏览器的兼容性，必须设置页面背景<body bgcolor="#FFFFFF">
网站文件命名规范

文件命名的原则：以最少的字母达到最容易理解的意义。

索引文件统一使用index.html文件名(小写)
index.html文件统一作为"桥页"，不制作具体内容，仅仅作为跳转页和meta标签页。主内容页为main.html

按菜单名的英语翻译取单一单词为名称。例如：
关于我们 \aboutus
信息反馈 \feedback
产 品 \product
所有单英文单词文件名都必须为小写，所有组合英文单词文件名第二个起第一个字母大写；
所有文件名字母间连线都为下划线

图片命名原则以图片英语字母为名。大小原则写同上。
例如：网站标志的图片为logo.gif
鼠标感应效果图片命名规范为"图片名+_+on/off"。
例如：menu1_on.gif/menu1_off.gif

五. 其它文件命名规范
1.js的命名原则以功能的英语单词为名。
例如：广告条的js文件名为:ad.js
2.所有的CGI文件后缀为cgi
所有CGI程序的配置文件为config.cgi
网站项目管理规范手册

一.概念

网站项目管理就是根据特定的规范、在预算范围内、按时完成的网站开发任务。

二.需求分析

项目立项

我们接到客户的业务咨询，经过双方不断的接洽和了解，并通过基本的可行性讨论够，初步达成制作协议，这时就需要将项目立项。较好的做法是成立一个专门的项目小组，小组成员包括：项目经理，网页设计，程序员，测试员，编辑/文档等必须人员。项目实行项目经理制。

客户的需求说明书

第一步是需要客户提供一个完整的需求说明。很多客户对自己的需求并不是很清楚，需要您不断引导和帮助分析。曾经有一次，我问客户：“您做网站的目的是什么？”他回答：“没有目的，只是因为别人都有，我没有！”。这样的客户就需要耐心说明，仔细分析，挖掘出他潜在的，真正的需求。 配合客户写一份详细的，完整的需求说明会花很多时间，但这样做是值得的，而且一定要让客户满意，签字认可。把好这一关，可以杜绝很多因为需求不明或理解偏差造成的失误和项目失败。糟糕的需求说明不可能有高质量的网站。那么需求说明书要达到怎样的标准呢？简单说，包含下面几点：
1.正确性：每个功能必须清楚描写交付的功能；
2.可行性：确保在当前的开发能力和系统环境下可以实现每个需求；
3.必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时"砍"掉；
4.简明性：不要使用专业的网络术语；
5.检测性：如果开发完毕，客户可以根据需求检测。

三.系统分析

网站总体设计

在拿到客户的需求说明后，并不是直接开始制作，而是需要对项目进行总体设计，详细设计，出一份网站建设方案给客户。总体设计是非常关键的一步。它主要确定：
1.网站需要实现哪些功能；
2.网站开发使用什么软件，在什么样的硬件环境；
3.需要多少人，多少时间；
4.需要遵循的规则和标准有哪些。

同时需要写一份总体规划说明书，包括：
1.网站的栏目和版块；
2.网站的功能和相应的程序；
3.网站的链接结构；
4.如果有数据库，进行数据库的概念设计；
5.网站的交互性和用户友好设计。

网站建设方案

在总体设计出来后，一般需要给客户一个网站建设方案。很多网页制作公司在接洽业务时就被客户要求提供方案。那时的方案一般比较笼统，而且在客户需求不是十分明确的情况下提交方案，往往和实际制作后的结果会有很大差异。所以应该尽量取得客户的理解，在明确需求并总体设计后提交方案，这样对双方都有益处。网站建设方案的包括以下几个部分：
1.客户情况分析；
2.网站需要实现的目的和目标；
3.网站形象说明；
4.网站的栏目版块和结构；
5.网站内容的安排，相互链接关系；
6.使用软件，硬件和技术分析说明；
7.开发时间进度表；
8.宣传推广方案；
9.维护方案；
10.制作费用；
11.本公司简介：成功作品，技术，人才说明等。

当您的方案通过客户的认可，那么恭喜你！您可以开始动手制作网站了。但还不是真正意义上的制作，你需要进行详细设计：

网站详细设计

总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化。详细设计主要是针对程序开发部分来说的。但这个阶段的不是真正编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该 包含必要的细节，例如：程序界面，表单，需要的数据等。程序员可以根据它们写出实际的程序代码。

四. 项目实施

整体形象设计

在程序员进行详细设计的同时，网页设计师开始设计网站的整体形象和首页。
整体形象设计包括标准字，Logo，标准色彩，广告语等。 首页设计包括版面，色彩，图像，动态效果，图标等风格设计，也包括banner，菜单，标题，版权等模块设计。首页一般设计1-3个不同风格，完成后，供客户选择。
记住：在客户确定首页风格之后，请客户签字认可。以后不得再对版面风格有大的变动，否则视为第二次设计。

开发制作
到这里，程序员和网页设计师同时进入全力开发阶段，需要提醒的是，测试人员需要随时测试网页与程序，发现Bug立刻记录并反馈修改。不要等到完全制作完毕再测试，这样会浪费大量的时间和精力。项目经理需要经常了解项目进度，协调和沟通程序员与网页设计师的工作。

调试完善

在网站初步完成后，上传到服务器，对网站进行全范围的测试。包括速度，兼容性，交互性，链接正确性，程序健壮性，超流量测试等，发现问题及时解决并记录下来。
为什么要记录文档呢？其实本软件工程本身就是一个文档，是一个不断充实和完善的标准。通过不断的发现问题，解决问题，修改，补充文档，使这个标准越来越规范，越来越工业化。进而使得网站开发趋向规范，趋向合理。

宣传推广

宣传推广的基本方法有：
1.网页里设置适当的META标签；
2.各搜索引擎登录；
3.准备新闻稿件在各新闻公告板发表；
4.合理使用Email邮件列表；
5.广告条交换；
6.付费广告。
至此，网站项目建设完毕，将有关网址，使用操作说明文档等提交客户验收。如果需要维护，另行签定维护项目。

维护

网站成功推出后，长期的维护工作才刚刚开始，我们需要做到的是
1.及时响应客户反馈；例如可以采取Email自动回复功能，然后在1-3个工作日里解决问题，再次回复；
2.网站流量统计分析和相应对策；
3.尽量推广和使用您的网址；
4.网站内容的及时更新和维护。

五.遵循的规范

1.网站建设目录规范
2.网站文件命名规范
3.网站建设尺寸规范
4.网站首页head区代码规范
5.网站连接结构规范
网站建设尺寸规范

页面标准按800*600分辨率制作，实际尺寸为778*434px
1024*768分辨率实际尺寸为：1002*603PX

页面长度原则上不超过3屏，宽度不超过1屏

每个标准页面为A4幅面大小，即8.5X11英寸

全尺寸banner为468*60px，半尺寸banner为234*60px，小banner为88*31px

另外120*90，120*60也是小图标的标准尺寸

每个非首页静态页面含图片字节不超过60K，全尺寸banner不超过14K

C#写文件

2007-12-31 01:01C#文件处理操作必须先导入命名空间：using System.IO;

//实现背景：一个文本框、一个按钮、VS2005

方式一：用FileStream

//实例化一个保存文件对话框
            SaveFileDialog sf = new SaveFileDialog();
            //设置文件保存类型
            sf.Filter = "txt文件|*.txt|所有文件|*.*";
            //如果用户没有输入扩展名，自动追加后缀
            sf.AddExtension = true;
            //设置标题
            sf.Title = "写文件";
            //如果用户点击了保存按钮
            if(sf.ShowDialog()==DialogResult.OK)
            {
                //实例化一个文件流--->与写入文件相关联
                FileStream fs = new FileStream(sf.FileName,FileMode.Create);
                //获得字节数组
                byte [] data =new UTF8Encoding().GetBytes(this.textBox1.Text);
                //开始写入
                fs.Write(data,0,data.Length);
                //清空缓冲区、关闭流
                fs.Flush();
                fs.Close();

            }

方式二：用StreamWriter

//实例化一个保存文件对话框
            SaveFileDialog sf = new SaveFileDialog();
            //设置文件保存类型
            sf.Filter = "txt文件|*.txt|所有文件|*.*";
            //如果用户没有输入扩展名，自动追加后缀
            sf.AddExtension = true;
            //设置标题
            sf.Title = "写文件";
            //如果用户点击了保存按钮
            if (sf.ShowDialog() == DialogResult.OK)
            {
                //实例化一个文件流--->与写入文件相关联
                FileStream fs = new FileStream(sf.FileName, FileMode.Create);
                //实例化一个StreamWriter-->与fs相关联
                StreamWriter sw = new StreamWriter(fs);
                //开始写入
                sw.Write(this.textBox1.Text);
                //清空缓冲区
                sw.Flush();
                //关闭流
                sw.Close();
                fs.Close();
            }

方式三：用BinaryWriter

//实例化一个保存文件对话框
            SaveFileDialog sf = new SaveFileDialog();
            //设置文件保存类型
            sf.Filter = "txt文件|*.txt|所有文件|*.*";
            //如果用户没有输入扩展名，自动追加后缀
            sf.AddExtension = true;
            //设置标题
            sf.Title = "写文件";
            //如果用户点击了保存按钮
            if (sf.ShowDialog() == DialogResult.OK)
            {
                //实例化一个文件流--->与写入文件相关联
                FileStream fs = new FileStream(sf.FileName, FileMode.Create);
                //实例化BinaryWriter
                BinaryWriter bw = new BinaryWriter(fs);
                bw.Write(this.textBox1.Text);
                //清空缓冲区
                bw.Flush();
                //关闭流
                bw.Close();
                fs.Close();
            }

C#缓存流示例------>用缓存流复制文件

C#文件处理操作必须先导入命名空间：using System.IO;

背景：使用VS2005、一个按钮、一个窗体、C#缓存流、把D:\KuGoo\爱得太多.wma复制到D:\并更名为love.wma,即：D:\love.wma

在按钮的Click事件中添加如下代码：

private void button1_Click(object sender, EventArgs e)
        {
            //创建两个文件流 一个是源文件相关，另一个是要写入的文件
            FileStream fs = new FileStream(@"D:\KuGoo\爱得太多.wma",FileMode.Open);
            FileStream fs2 = new FileStream(@"D:\love.wma",FileMode.Create);
            //创建一个字节数组，作为两者之间的媒介
            //好比两个人拿苹果，这个字节数组就好比一个篮子，一个人作死的把苹果送到篮子里面，
            //而我就可以作死得拿苹果，通过这个媒介我们互不干扰，
            //不需要互相等待【她往篮子里面放了苹果我才可以去拿】，提高了效率
            byte[] data = new byte[1024];
            //创建两个缓冲流，与两个文件流相关联
            BufferedStream bs = new BufferedStream(fs);
            BufferedStream bs2= new BufferedStream(fs2);
            //fs作死的读，fs2作死的写，直到fs没有字节可读fs2就不写了
           //好比，一个人作死的往篮子里面丢苹果，另一个人作死得往篮子里面拿苹果，直到篮子里面没有苹果拿了为止
            //即-->那个人没有苹果往篮子里面放了
            while(fs.Read(data,0,data.Length)>0)
            {
                fs2.Write(data,0,data.Length);
                fs2.Flush();
            }
            //关闭流，好比两个人累了，都要休息 呵呵o(∩_∩)o...
            fs.Close();
            fs2.Close();
        }

 

C#内存流示例----->用内存流来读取图片
C#文件处理操作必须先导入命名空间：using System.IO;

背景：一个窗体、一个pictureBox、一个lable[没有选择图片,lable的text为"图片未选择"],在pictureBox1的Click事件中添加如下代码：

private void pictureBox1_Click(object sender, EventArgs e)
        {
            //实例化一个打开文件对话框
            OpenFileDialog op = new OpenFileDialog();
            //设置文件的类型
            op.Filter = "JPG图片|*.jpg|GIF图片|*.gif";
            //如果用户点击了打开按钮、选择了正确的图片路径则进行如下操作：
            if(op.ShowDialog()==DialogResult.OK)
            {
                //清空文本
                this.label1.Text = "";
                //实例化一个文件流
                FileStream fs = new FileStream(op.FileName, FileMode.Open);
                //把文件读取到字节数组
                byte[] data = new byte[fs.Length];
                fs.Read(data, 0, data.Length);
                fs.Close();

                //实例化一个内存流--->把从文件流中读取的内容[字节数组]放到内存流中去
                MemoryStream ms = new MemoryStream(data);
                //设置图片框 pictureBox1中的图片
                this.pictureBox1.Image = Image.FromStream(ms);
            }

        }

2007年11月17日 星期六 下午 08:14