详情
本书是编程风格方面的奠基之作，在国外和国内的技术圈中享有盛誉。它是一本很古老的书。30 年的岁月依旧无法掩盖其中的真知灼见。它用简单的语言和篇幅，介绍了数十条可以不断流传的程序设计最佳实践，对于程序员具有非常重要的现实意义。
书名：编程格调
ISBN：978-7-115-37952-8
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [美] Brian W.Kernighan P.J.Plauger
译 高 博 徐章宁
责任编辑 陈冀康
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书是编程惯用法和规则的实践指南。全书从表达、控制结构、程序结构、输入和输出、常见错误、效率和测试工具、方档等多个角度，概括了程序设计的最佳实践或规则，并通过代码示例加以分析和阐释。
本书两位作者都是程序设计领域的大师级人物。他们四十年前在本书中给出的70多条最佳实践和规划，大多数在今天仍然适用。
本书堪称计算机专业人士和程序员的必读的经典之作，适合于不同层级的程序员和计算机相关专业的学生参考阅读。
Brian W. Kernighan，全球知名、德高望重的计算机先驱，在程序设计方法论和软件工程方面做了大量开创性的工作。他曾长期在贝尔实验室工作，现在普林斯顿大学计算机科学系任教。他著有数本经典教材，包括与 Dennis Ritchie合著的传世之作The C Programming Language、与Rob Pike合著的The Practice of Programming，以及最近出版的科普图书D is for Digital等。他还是AWK编程语言的发明者，这种语言广泛地应用在UNIX/Linux应用中。“K&R C”和“AWK”中的“K”都代表Kernighan。
P.J. Plauger，全球知名的计算机科学家、C/C++技术专家以及技术图书作者，更是数个标准C/C++程序库的作者。他曾经在贝尔实验室工作，现在任美国 Dinkumware公司总裁。他曾经担任 C/C++ Users Journal 高级编辑，也是The Standard C Library、Standard C: A Reference和The Standard Template Library等图书的作者。
高博，1983年生，毕业于上海交通大学。目前在互联网金融创业公司任首席产品官兼首席质量官，在信息科学和工程领域有近15年实践和研究经验。酷爱读书和写作，业余研究兴趣涉猎广泛。译著包括图灵奖作者高德纳的《研究之美》和布鲁克斯的《设计原本》，以及Jolt大奖作品《元素模式》等，出版翻译作品计近百万字。
徐章宁，1984年生，就读于上海交通大学，硕士毕业后就职于EMC中国卓越研发集团，现任EMC公司高级系统管理工程师，从事软件运维工作多年，钟爱开源软件。对各类知识有广泛兴趣，平日喜爱参与问答网站讨论，热爱读书摄影和写作。
这本尘封了近40年的著名教材此次重新翻译，既是我们向前辈的致敬，也是我们重读经典的努力和尝试。译者第一次看到本书，是在1998年参加全国信息学竞赛期间，彼时也正是计算机工业在中国进入黄金发展期的前夜，读后的心潮澎湃历历如昨。此后，在和很多业界知名的前辈如Donald E. Knuth、Bjarne Stroustrup和Anders Hejlsberg等交流的过程中，也不止一次地听到本书的名字，可见本书影响之纵深。
为什么本书能有如此的影响力？也许会有人说，是因为作者的名气，但这是事后的见解。两位作者的功底固然是力透纸背，可放在当时的历史背景下，其实主要的原因却在于，它开创了一个程序设计习惯用法（idiom）的先河。和两位作者此后的作品相比，本书中很多地方反而可以看出，他们当时还是以新锐作家的口吻，在创立自己的观点，而非早已站在制高点处向大众布道而已。这是本书最为宝贵之处，我们从中可得以窥见现在已经几乎成为常识的观点，发端于怎样的初心，并经历过怎样的磨砺，才逐渐站稳了脚跟。也正是因为如此，本书对于当时的软件业界而言，不啻是黑暗中的一道闪电，照亮了人们前行的步伐，所以才能在这么多高手的心中留下难以磨灭的印象。
而对于今天中国的软件业界，本书的重新翻译和出版，同样意义重大。求新、求异，却不重视程序设计基本功和工程素养的风气，近年来有令人不安的抬头趋势。我们思考再三，决定将本书的译名定为《编程格调》，也是为了强调书中反复申明、历久弥坚的习惯用法以及它们反映出来的宝贵思想，对于当前现实的指导意义。阅读本书，可以回答一个非常基本的问题：怎样去构建软件、构建怎样的软件，才能说成是“有格调”的，才能走得稳、走得远。
当然，对于一本近40年前的出版物，我们不可能要求它尽善尽美。比如书中采用的编程语言，在今天看来已经不是非常流行。但一个合格的程序员，应该可以比较迅速地掌握一门新语言的结构，至少看懂一段代码所要表达的含义。正如我国著名画家齐白石所言：“学我者生，似我者死”。我们要学会学习，吸收书中观点的精华，并和自己当下的工程实践相结合，而非邯郸学步。
感谢人民邮电出版社的陈冀康编辑为促成本书的出版而作出的大量努力，EMC中国卓越研发集团的徐章宁高级工程师和本人一起完成了本书的重新翻译工作，这里也要向他的辛勤工作表达由衷的感谢。本书成稿的过程中，上海交通大学计算科学与技术系的张尧弼和梁阿磊教授、赛门铁克中国区技术负责人汤瑞欣总监、华为存储事业部严华兵高级经理和开源社区事业部杜玉杰工程师，以及GitCafé CEO姚欣宇等都参加过审阅并提出了宝贵意见。当然，由于译者能力所限，本书中仍然不可避免地存在更多的纰漏，这些理应由我们负责。我也想借此机会向在工作和生活上给了我莫大支持的父母和爱妻沈靓表达我内心最深处的敬意，希望本书的出版能给你们带来快乐。
2015年元旦
于杭州苏堤
自《编程格调》初版面世以来，计算机程序设计实践已经今非昔比。关于编程格调的讨论已登大雅之堂。历经“代码写过算数”的漫长岁月，学生、教师，以及计算界专业人士已经意识到程序可读性的重要。结构化程序设计已经作为一种极有价值的编程原理被普遍接受，而且人们也逐渐意识到，设计乃是一个重要的编程阶段，而这在过去经常是被忽视的。
我们对《编程格调》进行了一番彻底改写。在初版中，我们避免在任何地方直接使用“结构化程序设计”，以远离当时甚嚣尘上的宗派之争。而现在，人们的热情已经消退，我们反而感觉是时候讨论已在实践中经受住考验的结构化程序设计话题了。
本书再版时，加入了新的一整章来讨论程序结构，阐明如何运行自顶向下的设计写出结构良好的程序。全书都在讨论设计中遇到的种种问题。我们也谨慎地运用伪代码作为一种程序开发工具。
我们也重写了初版中的大量示例，以反映出（至少我们希望如此）对于如何编好程序的更深入理解。同样，书中还引入了不少新示例。初版中不少拿来作为榜样的示例，现在却成了反面教材。再版还加入了一些新的习题。最后，我们扩展、深化了作为编程格调的种种规则。
对于慷慨授权我们在书中重印他们教材中程序的作者和出版商，我们再次感觉受益匪浅。回过头来看我们自己写的程序就能明白，撰写出优秀的程序有着怎样高的要求。
我们同时要感谢阅读再版草稿的朋友，尤其要感谢 Al Aho、Jim Blue、Stu Feldman、Paul Kernighan、Doug McIlroy、Ralph Muha和Dick Wexelbalt，他们曾提出过非常有价值的建议。
Brian W.Kernighan
P. J. Plauger
仅仅通过听取一般原理，就想很好地掌握程序设计，这是不可能的事。想要学好程序设计，就要一次又一次地观察体会实际的程序是如何通过运用一些久经实践考验的原理和常识，方得持续改进的。程序审阅能够教会人们如何重写程序，再进一步教会人们如何写出更好的程序。
本书就是建立在对大量“实际”程序的研究之上的成果，其中的每个程序都有着一种或数种格调方面的毛病。我们讨论了每个例子存在的缺点，并采用更好的方式将其重写，然后由这个特殊情况推出一般原理。我们的出发点是实用的、接地气的。我们关心的是要改进当前程序设计的工作，而不是想要创建一套繁杂理论来告诉人们如何进行程序设计。所以，本书可以用作任何水平的程序设计课程的补充材料，也可以让已有经验的程序员们读后获得温故而知新的效果。
书中的所有示例皆以Fortran和PL/Ⅰ写就，因为这两种语言不仅被广泛采用，而且互相类似，只要会看其中一种，则另一种也不言自明（无论采用哪一种语言来写程序，我们都避免采用复杂结构，遇到不可避免的习惯用法时，也会加以解释）。而有关编程格调的原理，则适用于一切语言，包括汇编码。
我们的目标在于仅运用少量的篇幅即能讲授编程格调的妙处，所以我们有一说一。贯穿全书的是一系列规则，这样方能彰明我们习得的教训。每一章都以一段总结和一组“思考要点”收尾，其中会给出一些练习，并使得读者有机会继续考查正文中没有讲全的一些议题。我们在书的末尾将规则集中列出，以飨读者。
这里特别要讲一讲本书中程序实例的来源，它们全部选自其他的程序设计教科书。换言之，我们不通过自己撰写程序来论证我们的观点，而是使用那些已经完成的产品，即那些由富有经验的程序员撰写并且发布的程序。这些程序往往就是新程序员们入行后见到的首批程序，本来我们希望这些例子能起到编程格调的示范作用，遗憾的是却常常事与愿违。这些教科书中举的例子往往本想说明自己在某个方面做得出色，结果却适得其反，暴露了问题。（我们不会故意使坏，通过断章取义来使程序在该语境下显得写得不好。）
我们还要特意声明：我们不是要以个人或集体名义批判这些教科书的作者们。缺点的存在仅仅表明我们不过都是凡人，在编程或写书这样压力巨大的脑力劳动中，有些事情做得不完美诚属难免。毫无疑问地，本书中所提到的一些“好”程序，一定也会被未来的某位作者举作“坏”程序的反面例子。我们也诚心地希望未来的这位作者及其读者也能通过仔细研究这些程序的经验而学到东西。
一本编程格调手册的问世，离不开很多人开创性的工作，他们中有相当数量的人就写过非常出色的教科书。比如，D. D. McCracken和G. M. Weinberg很久以来就在教学中呼吁简单性和明晰性的极端重要。E. W. Dijkstra和Harlan Mills在结构化程序设计方面取得的成果，帮助我们明确了指定控制流的相关规则。本书的篇章安排和语言风格都深受W. Strunk和E. B. White的名著The Elements of Style一书的影响，我们通过集中精力于格调的本质和实用方面，来达到该书的简明程度。
我们受益于太多人的帮助和鼓励，特别是授权我们复用在本书正文中的程序作者和出版社，这样的合作极其难能可贵。
我们在贝尔实验室的朋友和同事们提出过大量有用的建议，正是由于这些建议，我们得以在出版前纠正了不少本来可能贻笑大方的谬误。特别要感谢 V. A. Vyssotsky与我们一起进行了数次修订工作，对于他富有洞见的评论和对本书成形过程中每一阶段的热情支持，我们深表谢意（还有，我们在书中“无耻盗用”了他的几句格言）。我们还想感谢 A.V. Aho、M. E. Lesk、M. D. Mcllroy 和 J. S. Thompson给予本书的时间投入和莫大帮助。
我们之所以能把手稿直接录入PDP 11/45、编辑源码、校验程序，并对最终版文本排版，所有这一切都要仰仗一个独一无二的、灵活的操作系统，这就是UNIX。K. L. Thompson和D. M. Ritchie是UNIX的首席架构师，除了帮我们校稿以外，他们还在我们写书时帮我们最大程度地利用好 UNIX 系统。J. E. Ossanna 编写了排版程序并修改了数处，以满足我们的特殊要求。在此致谢。
Brian W. Kernighan
P. J. Plauger
考查以下程序片断。
只要对Fortran语言有一定的了解，我们就知道，这个双重嵌套的DO循环是要对具有N×N个元素的矩阵V的各个元素赋以某值。怎样的值呢？I和J是正的整型变量，在Fortran语言中，整型除法会向零取整。因此，当I小于J时，（I/J）为0。反之，当J小于I时，（J/I）为0。而当I等于J时，两个因数皆为1，所以（I/J）*（J/I）等于1，当且仅当I等于J，否则皆为0。这段程序意在将V的对角元素置1，而其余元素置0（从而V成为一单位矩阵）。多么聪明啊！
果然如此吗？
设想，你是在一个较大的程序中遭遇了这段程序。如果你对Fortran语言造诣颇深，那你可能会很欣赏此处对整型除法的妙用。但也有可能你会觉得吃惊不小，因为明明有更简单的做法，这里采用的做法却要做两次除法、一次乘法和一次从整型到浮点型的强制转换。更大的可能是，你不得不重复上面的推理过程。极大的可能是，你只是有了一个囫囵的印象，知道它向数组中放置了某些有用的东西。只有当你有了强烈的动机，比如要对程序进行调试或改动时，才会回过来猜测它的确切含义。
这段程序这样写会更好。
先将各行置0，然后将对角元素置1。现在含义十分明确，代码运行得也更快了。如果我们是用PL/Ⅰ撰写程序的，就可以表达得更明显。
无论哪种情况，要点在于要使代码的意图不会被误解，而非炫技。在这里，存储空间和执行时间相对而言都不重要，因为建立单位矩阵一定是整个程序中的一小部分。难懂代码的问题在于它难以调试和修改，而这些已经成为计算机程序设计中最困难的问题。此外，过分聪明的程序会增加与原意发生偏离的危险。
撰写简洁的程序——不要耍小聪明
暂停一下，让我们反思一下到目前为止我们都做了些什么。我们研究了一段程序，该程序原样引自某本程序设计教材。我们讨论这段程序的优点和缺点，然后着手对其加以改进。（未必达到完美——仅仅是改进。）在分析和改进中，我们总结出一条规则或是一般结论，该规则听起来不免有点像是有着纯粹抽象的普适性，但它合情合理，在遇到具体情况时就能具体运用。
本书其余部分大抵如此，即从教材中选取实例，尔后是讨论和改进，再得出规则，如此反复。读完本书之后，你应当学会评判自己的代码。更重要的是，你应该具备了一开始就把程序写得更好的能力，从而不会十分招惹非议。
我们尝试按逻辑由浅入深的顺序对例子进行分类，但是正如你所见，实际程序如同文学习作，经常同时违反若干条良好实践的规则。因此，我们的分类不免有时会显得有些随意，而且有时也不得不话分两头。
虽然大部分的例子都比刚才的那个要长，但也不会长得过头。即使是初学者，通过讨论，也可以跟得上。实际上，大部分长程序都会在你眼皮底下施以缩身术。完全正好的尺寸往往只是幻想，它只不过体现了对于程序存在改进的要求。
所有的例子皆以Fortran和PL/Ⅰ写就，但是你只熟悉其中一种语言，甚至一种也不熟悉，你所能遭遇的困难都不会超过程序本身的尺寸。打个比方，你可能不会用PL/Ⅰ编程，但你肯定能读懂PL/Ⅰ程序，并理解我们讨论的要点，边读边学会让你更轻松地掌握PL/Ⅰ。
例如，这里就是一小段PL/Ⅰ程序，我们将在第4章中详细讨论整个程序。
第一个GOTO和第二个GOTO纠缠在一起，看起来有点乱。用“<=”代替“>”，就可以改写如下。
语句少了一个，逻辑变简单了，OVFLO也变得多余了。教益是什么呢？分支和分支不要纠缠在一起，把关系检测表达式调个方向，程序就更容易理解了。下面我们看一个有着相同问题的Fortran例子，这么一来就可以得出一个重要的结论，语言细节虽然各自不同，但编程格调的原理则是一致的。分支与分支纠缠在一起的话，在任何语言中都会引发困扰。哪怕你是用COBOL、BASIC、汇编或其他语言，你在此处习得的原理都可以应用。
上例看起来有小题大作之嫌。无论如何，原始的程序含义还算是很清楚的。问题在于，一个小问题也许不会造成大的破坏，但是多处引发困扰语句形成的积累效应，就会使程序十分费解了。
下面看个稍长些的例子。
以下是个求某数（X）平方根（B）的典型程序：
由于程序稍长，我们分成若干层次进行研究。比如，在进入细节之前，先想想这个程序是不是那么“典型”。作为一个求平方根的子例程，不大可能做成一个主程序的样子，还需要自行读入数据——带有一个自变量的函数就非常够了。即使我们真的需要一个主程序来计算平方根，又有多大可能会希望它在停止运行前只算出来一个平方根呢？
这种将程序限制过死的趋势，提醒了我们应该怎样编写想用于通用目的的程序。不久我们就将遇到只跟踪不多不少17位销售的程序，只对正好500个数排序的程序，以及只走一个迷宫的程序。我们猜想，这样把程序改写为通过编译器获得参数的场合，是非常多的。
让我们继续看这个平方根程序。它的实现采用了牛顿法，这的确是许多求平方根库例程的核心（但我们不必精确地了解它如何运作）。给以适当的数据，这个方法很快就会收敛。不过，如果 X 是个负数，此程序就会陷入死循环。（不信可以一试。）好的程序应当能够返回错误信息或诊断消息。当 X 为 0 时，这个程序会在行号为2的语句处算个不休，这种情况应该分开处理。0的平方根就给一个结果0即可。
即使X取严格的正值，这一程序也可能算出无意义的结果。问题出在收敛校验的运用上。
应该利用Fortran语言特性，把第二行改成：
为避免有人把10.E-6看成“10的-6次幂”看错，第三行中的常数应改成1.0E-5，甚至改成0.00001都行。其实，为了直抒胸臆，不要绕弯子，这头3行应该直接写成：
现在，这个校验的含义就非常清楚了。但可惜它有错。
若X充分大，两个尝试平方根的绝对差值就很有可能永远不小于1.0E-5这个随心所欲选择的收敛阈值，除非这个绝对差值严格为零。因为，计算机表示的数字精度有限。此绝对差值是否总可以收敛到 0，属于数值分析上的一个尚无定论的问题。如果X取较小值，则这个标准早早地就会被满足，此时还远未得到一个理想的估值。如果我们采用相对于原始数据的趋近估计，而非绝对收敛作为标准，则对于大多数的正自变量，均可获得5位有效数字。
修改过的程序还够不上说是求平方根的典型例程的标准，我们也不打算深入浮点数计算的技术细节，来完成这个例程。可是，这一程序的通用性倒是足够典型，评判和改写后它变得好多了。
再举本章的最后一例，通过研究我们会发现它有若干缺点，以下是个排序例程。
程序不但缺乏通用性，而且算法漏洞百出，代码写得不明不白，还有一个印刷错误。其中
这一行中的“-”应该是个“=”。这个程序想方设法要达成的目的之一，在于展示DO循环体可以通过向外跳转，然后跳转回来的方法进行扩展的特性，不过在本例中，DO循环体外加扩展的语句能够一起写到一行里。
关于这一点，一个更重要的问题在于，从根本上说，是否应该鼓励程序员去使用扩展范围。在计算机程序中非必要的跳转，已经被证明是错误的一大来源，并且通常这表明程序员没能很好地掌控代码走向。本例中杂乱无章的语句行号，往往也是思想混乱的外在表现。
此程序还有其他的毛病。它读入500个数，每张卡片一个，然后简直是以最低可能的效率对这些数排序，方法是将每个数与−999到+999之间的所有整数进行比较。它只做一次，只处理一组数，然后就停止了。
等等，好像哪里不对。由于指定了I4输入格式，在正号可能被忽略的前提下，可能读入的最大正数是9999，而这个程序从一开始的设计来说，就无法列出4位数。要纠正这个问题，算法的耗时就得增加5倍都不止，而通用性却一点儿都没有增加。如果套用这种方法来扩展程序以处理更大的整数，速度会减慢若干数量级。要让它处理浮点数，更是想都不要想了。
由于我们从根本上不赞同这个程序的思路，这里就不重写它了。（第7章中列举了几个更好的排序程序。）我们只想表明，同一程序可从不同的视角来看。批判性的阅读不要止于发现一个键入错误，而是要发现不良的整体思想。在后面各章中，我们将探讨以上看到的，以及其他的问题，这些都会极大地影响到编程格调。
第2章开篇，我们会研究如何将单个语句写得简洁。写好算术表达式和条件语句（IF），通常是计算机程序设计的基础课中首先要讲的内容。在深入其他语言特性之前，先把这些基础牢牢掌握。
第3章讨论程序的控制流结构，即怎样通过循环语句和决策语句来控制程序流向。同时，这章还说明了如何表示数据能使程序设计工作变得尽可能轻松，以及采用何种数据结构可以获得清晰的控制流。第4章的主题是程序结构，讨论了如何将一个程序分解成易于处理的块。这两章花费了不少笔墨在正确使用结构化程序设计及坚实的设计技术上。
第5章考查输入和输出，包括如何在撰写程序的过程中，使其免受差劲的输入数据伤害，以及如何组织输出以使程序在运行中获取尽可能多的收益。第6章研究了许多常见错误，并讨论了如何发现和改正它们。
和通常的做法相反，效率和文档在最后两章才出现。虽然这两个主题都很重要，也很值得学习。但我们认为对它们的重视程度有点过头了，尤其是在很多入门课程中存在这个不良的偏重，而程序简洁性等格调却因此没有得到应有的关注。
以下是我们在评判程序时一些通行规则的说明。
（1）程序尽量以本来面目示人，只要打印系统支持。格式、印刷错误和词法错误也照单全收。（例外情况是，有 3 个 PL/Ⅰ程序的表示方法从48个字符改成了60个字符。）
（2）我们的常规做法是从程序中摘录片断，这样可以集中精力在其本质方面。我们相信，所讨论的缺点是代码内固有的，并非由于断章取义而造成或加重了问题。我们尽可能在摘录时不失语境，也在想方设法从根本上解决程序的原始版本中想要解决的问题，只有这样对比才能做到公平，即使有时这样做会使得我们无法穷尽程序的改善空间。
（3）我们不会因为例子使用了非标准语言特性（例如，Fortran语言中的混合模式算术[1]）而对其吹毛求疵，除非这种用法很不常见或非常危险。大多数编译器都能接受非标准结构，而标准本身也是与时俱进的。不过还是要牢记，不常用的特性难以移植，而环境一旦变化，它们是首当其冲出现状况的。
我们自己使用的Fortran语言严格遵循1966年的ANSI标准，除了用引号包含的Hollerith字符串（我们拒绝进行字符计数）。所用PL/Ⅰ符合IBM最新编译器版本1、发行版3.0的标准。虽然我们也见过新版的Fortran和PL/Ⅰ版本，它们使更好的程序设计成为可能，但尚未得到广泛应用，所以我们并未使用它们来编写任何示例。
（4）在针对数值算法的讨论中（例如，前面的平方根程序），我们不打算诊疗其全部症状。诸如溢出、有效精度丢失，以及其他一些数值方面的小错的对策，超出了本书的范围。但我们坚持认为，最基本的预防措施还是要有的，比如用相对差值校验代替绝对差值校验，以及避免被零除等，为的是保证只要给定合理的输入，就可以收获正确的计算结果。
（5）本书中的每行代码都通过了编译，直接利用程序文本即可被计算机正确读取。所有程序均经过测试（Fortran程序的测试机是一台Honeywell 6070，PL/Ⅰ程序的测试机是一台IBM370/168）。Fortran程序经过了一个校验器的校验，以监督它们是否符合ANSI标准。
即便如此，错误还是在所难免。我们鼓励读者抱着怀疑的态度，来看待我们的每句看上去不太顺眼的话。请动手做校验，彻底检查一番。不要把计算机的输出结果奉为圭臬。假如你学会了谨慎对待别人的程序，你也就能够更好地审视自己的程序了。
1.1 n×n的矩阵有n2个元素，因此，初始化这么一个矩阵就需要n2个赋值语句。采用经典方法完成两个n×n矩阵的乘法，或求解由n个n元方程所构成的方程组，要做n3阶运算（这些都是矩阵处理程序的日常工作）。试提出相关论据以支持下列猜想。
如果n≥10，初始化矩阵所花费的时间无关紧要。
如果n<10，初始化矩阵所花费的时间无关紧要（提示：输入和输出时执行的转换比算术费时要多）。
1.2 在本书的初版中，我们编写过求平方根的例程如下。
这个程序更“高效”，因为它没有重复校检。你喜欢哪个版本？为什么？这个改变造成多少时间和空间差异？这两者都彰明了Fortran语言的什么不足之处？
1.3 在求平方根的例程中，我们看到校验时采用1.0E-5这一绝对阈值作为收敛标准很危险，所以建议采用某种相对标准代替。如何把下列函数用到我们的例程中？
AMAX1是个Fortran函数，它返回两个或两个以上浮点数中的最大值。上述函数在求平方根的例程中可能遇到的所有值都能得出正确结果。但是如果是在更一般的场合下，有没有什么X和Y的值会让这个函数出错？
[1] 指Fortran语言中，在算术表达式中混用整型和浮点型。一般规定，操作数中只要有一个是浮点型，则结果为浮点型，否则为整型。
