The Elements of Programming Style, 2nd Edition

windstorm 2009-12-21 0

挺好得，就是Fortran太难懂

Neckau 2015-10-20 0

还不错啦，不过现在读有点晚了，大部分都是在常年编程中会得出的概念。

Luffy 2012-01-06 0

好像跟兔子换了本Lonely Planet的书。

interskh 2008-12-29 0

经典图书啦.

bigpiglet 2013-01-28 0

看的是摘要的翻译版本，这些原则都还蛮是实用的。

Dr.J 2013-03-07 0

A timeless classic.

Ljhero 2014-05-16 0

经典的编程风格指南。虽然里面示例是Fortran和PL/I代码，但总结的编写优秀代码的规则具有普遍性，比如不要过早优化，过度注释等。

Reading 2012-06-03 0

可惜是针对Fortran

曹磊 2014-12-28 0

这些rules应该在刚学编程的时候就介绍。另，FORTRAN和PL/I读起来很吃力，字母全是大写的高级语言看起来跟汇编语言差不多

积木 2015-11-27 0

FORTRAN!!!!

軒轅鍾書 2013-11-25 1

很多建议还是很好的，特别是关于Input的validity，cover边界值等，这是之前自己一直忽视的。其余部分，简言之：programming也是注释的一部分；coding首先是正确，然后清晰、健壮，再是高效；各个部分要做到“增之一分则太长，减之一分则太短，着粉则太白，施朱则太赤。”

windstorm 2009-12-21 0

挺好得，就是Fortran太难懂

Neckau 2015-10-20 0

还不错啦，不过现在读有点晚了，大部分都是在常年编程中会得出的概念。

Luffy 2012-01-06 0

好像跟兔子换了本Lonely Planet的书。

interskh 2008-12-29 0

经典图书啦.

bigpiglet 2013-01-28 0

看的是摘要的翻译版本，这些原则都还蛮是实用的。

Dr.J 2013-03-07 0

A timeless classic.

Ljhero 2014-05-16 0

经典的编程风格指南。虽然里面示例是Fortran和PL/I代码，但总结的编写优秀代码的规则具有普遍性，比如不要过早优化，过度注释等。

Reading 2012-06-03 0

可惜是针对Fortran

曹磊 2014-12-28 0

这些rules应该在刚学编程的时候就介绍。另，FORTRAN和PL/I读起来很吃力，字母全是大写的高级语言看起来跟汇编语言差不多

我想说两句

编程格调总结

萬軍 2015-07-05 0赞

一、表达
  1.写清楚
  2.保守使用临时变量
  3.明白无歧义
  4.不要自己造所有的工具
  5.确保判断测试条件清楚易读

二、控制结构
  1.先用你顺手的高级语言写一遍程序，这时可以看清楚算法并作相应的调试，程序正确之后，再翻译成你编译器所处理的语言
  2.子例程和函数，把代码分成可独立管理的小段
  3.规划数据结构的时候要像规划控制流一样小心，尝试找到可以起到简化程序作用的数据表示形式

三、程序结构
  1.编写和维护大型程序唯一的方法是把它分解成一组函数、子例程和过程
  2.每一个模块应该只处理问题的一个方面，否则的话，模块就会变得大而复杂
  3.相对于其他模块，一个模块应该隐藏它如何完成工作的细节，否则这个模块就无法独立于其他模块来进行修改

四、输入和输出
  1.校验输入数据的合法于合理性
  2.保证输入数据不会违背程序的限制
  3.利用文件结束符号或结束标志来终止输入，不要让用户去计数
  4.识别输入错误并尽可能地恢复，不要一碰到错误就停止，也不要忽略错误了事
  5.在输入和输出时采用助记符，使得输入数据易于正确地准备，在输出时同时也將输入和默认值输出，并使得输出数据不言自明
  6.將I/O局限起来，不要散布在整个程序中。將处理文件结束和缓冲区等细节隐藏在函数中
  7.保证程序的结构反映出其所处理的数据

五、常见错误
  1.使用变量之前要初始化
  2.小心"差一"错误，确保在正确的次数下完成循环，对于等式的比较判断，确保有正确的分支处理
  3.检查数组的下标不要越界
  4.避免循环有多个出口
  5.检查程序的内部边界
  6.预防性编程，搞清楚哪些事可能出问题，并且添加代码以检查
  7.不要用浮点数来做累计，不要期望浮点小数数值遵循你熟悉的算术法则，他们不适用

六、效率和测试工具
  1.假如程序是错误的，再快也没用。
  2.让代码言简意赅。撰写时不要惦记着它运行得快。过早优化是万恶之源
  3.别为每个优化细节去操心，让编译器去照顾这些
  4.用心于算法，而非代码细节。记住，数据结构对算法的实现方式有显著影响
  5.在构造程序时放置测试语句，在决定"增效"之前先执行测试。在程序演进过程中，可將测试语句留下来随时运用

七、文档
  1.如果程序不正确，文档写得再好都没有用
  2.如果文档和代码不一致，那程序就没什么价值
  3.要在最大程度上使得代码本身就是自己的文档，如果做不到，重写代码而不是做文档的补充。好的代码需要的注释量要比坏的代码少
  4.注释提供的信息应该是从代码上无法获得的
  5.帮助记忆的变量名和标签，以及强调逻辑结构的代码布局，都有助于程序自身的文档化

石器时代的语言和规范

游侠Harry 2017-01-09 0赞

看这本书之前，我刚刚写了一个最原始的BASIC语言解释器作为Parser的练手项目。完成后，用了这个解释器试运行了经典的月球登陆车游戏，顺便分析了游戏的源代码，发现读起来各种不便

1. IF语句只能指定跳转行号，不支持ELSE
2. 只能用IF和GOTO来模拟WHILE循环
3. 没有函数调用，只能用GOSUB和RETURN来模拟子过程，阅读的时候为了找到RETURN回到哪得反复查半天。

当时我觉得这只是因为BASIC语言仅仅是给初学者当玩具用的语言，所以才这么难以阅读。

但接下来我就看了这本书，发现1和2在书中的FORTRAN语言也是存在的，因此，两位先贤花费了大量篇幅教导石器时代的开发者，要用条件和循环等分支结构，尽量的少用GOTO等等。并给出了一系列的规范。

但当支持结构式良好的编程语言PASCAL和C出现后，很多书中的规范已经成为自然而然的了。看来，这也是PASCAL和C迅速抢占市场的原因之一（后来C语言因为更贴近机器模型而打败了PASCAL，这是另外一个故事）。

看了这些石器时代的工具，想起来有位大牛说过“设计模式的存在都是为了弥补语言特性的缺陷”。

秦人（FORTRAN, BASIC）无暇自哀，而后人哀之；后人（C++，Java）哀之而不鉴之，以示后人复哀后人也。

一本老书，值得你啃

vinurs 2013-01-20 3赞

这是一本关于计算机编程风格的老书，就算只看最后的SUMMARY OF RULES都会觉得对你有所启发！
最好能通读这本书，结合书中的实例来理解那些RULES，你会知道什么是一种优秀的习惯，如果能将书中总结的RULES运用到实际编程中去，虽然不能让你成为一个优秀的程序员，但是会给你启发，让你通往优秀的程序员之路。
写出机器能看懂的程序很容易，写出人看懂的程序就不容易了！

读读Rules还是不错的

wuyve 2014-04-21 1赞

没研究过此书中代码所使用的Fortan和PL/I这两种语言，不过之前读过诸如Writing Solid Code、The Practice of Programming、编程珠玑一类的书，发现它们的Tips都是很类似的，比如：可读性、模块化、防御性编程、浮点计算和判等、数据结构决定程序、测试，等等。此书不知是不是编程建议类书籍的滥觞。
个人认为如果不是这两种语言的使用者，并且不打算为读这本书而专门学习，但具有其他语言的编程经验和类似书籍的阅读体验，此书速读一下Rules足矣。这大概也是在网上搜索此书经常发现是一份3页的Rules合集的原因。当然，读的时候应该联想之前的编程经验才能有所体会。
不过对于“Avoid temporary variables”这一条存疑。此书的示例中F1和F2仅仅是保存了两个中间结果，我认为在两种情况下，还是应该使用临时变量的：
1.具有实际意义，增加可读性——不过此时似乎又不应该仅仅是临时变量了；
2.(如在C中)将一个常用的变量放入寄存器中，避免多次进行存储器引用或函数调用，实例可见于《深入理解计算机系统》(CS:APP)图5-6。

一本老书,两个牛人,一堆经验

胖胖的大头鱼 2006-10-02 6赞

一本老书,写书的两个牛人.
Brian W. Kernighan,熟悉unix/c语言的没有不知道他老人家的大名的,文字漂亮,技术厉害.
P. J. Plauger,这位仁兄是为ms提供stl实现的公司头头(不过jjHou说那是可读性最差的一份stl实现,哈哈), 他很早就在c++里面混了,似乎是CUJ的高级编辑.
不过这本书全是fortran code,一堆堆的goto语句,真的是时代不同了,看代码基本不知道在干什么.
其中总结的rules倒是永恒的真理,今天来看也一点不过时,今天书市上所谓的教程序风格的书,不过是炒炒陈饭而已:)

软件开发中的“格调”

周兆熊 2015-04-07 1赞

在三年之前，我从学校毕业，进入公司，正式开始了软件开发工作。我从完成第一个开发任务的过程中学到了很多东西，包括：1)编写程序只是软件开发中的一个流程，并非全部；2)程序编写需要遵循一定的规范，远远不只是实现功能那么简单；3)程序编写者是程序的第一负责人，要对自己的程序进行充分的自测，而非只要程序编写完成便万事大吉了。大家在学校里面也编写过程序，但那并非规范的软件开发活动。从学校里面的“业余”进化为正式工作岗位上的“专业”，就需要提升我们的“编程格调”。
什么是“格调”？韦庄在《送李秀才归荆溪》的诗中曰：“人言格调胜玄度，我爱篇章敌浪仙。”对于一篇文章来说，“格调”是指文章的风格；而对于编程来说，“格调”是指程序的风格、样式。那么，什么是好的“编程格调”？《编程格调》一书为我们带来了答案。
本书的两位作者Brian W. Kernighan和P.J. Plauger是全球知名的计算机科学家，Brian W. Kernighan更是一位德高望重的计算机先驱，他与“C语言之父” Dennis Ritchie合著了经典书籍《The C Programming Language》。本书的译者之一高博老师也是“文津图书奖”译者(他所翻译的《信息简史》获得了“文津图书奖”)。如此一来，本书也已成经典。
本书篇幅不长，包括8个章节、共180页的内容，从表达、控制结构、程序结构、输入和输出、常见错误、效率和测试工具、文档等方面对“编程格调”展开了讨论。对于一些优秀的编程经验，本书提炼了出来，并放在了方框里面，以供读者参考。
我认为，对于一位开发人员来说，在软件开发中的“编程格调”体现在这三方面：第一，编程意识的“格调”；第二，程序设计的“格调”；第三，代码编写及测试的“格调”。

编程意识的“格调”
代码是程序员思维的体现，你在脑海里构思出怎样的程序，你就会编写出怎样的程序。因此，如果一个程序员没有要编写出优秀程序的意识，那么他们实际编写出来的程序也不会好到哪里去。
为了让自己的程序有“格调”，我们首先要在意识上严格要求自己，要提高自己的思维的水准。如此这般，才能够将意识的“格调”转变为程序的“格调”。

程序设计的“格调”
在动手编写代码之前，我们要对程序流程进行设计，也就是对程序进行宏观布局。
看过《三国演义》的人都知道，诸葛亮很善于宏观布局。在三国尚未形成之时，他就分析了当下局势，并为刘备指明了夺取天下的战略方针。在一场大战役打响之前，诸葛亮会分析天时和地利，并告诉各个将领一些排兵布阵的方法。他就是战争的总指挥，我们可以说他在战略上很有“格调”。
程序设计也与之类似。我们要分析软件需求，看哪些功能比较容易实现，哪些比较复杂。在弄懂了需求之后，我们要画出程序流程图及模块框架，并决定哪些模块可以采用现成的，哪些需要新开发，哪些功能要先实现，哪些可以后面再完成。只有有“格调”的设计才能够产生有“格调”的程序。

代码编写及测试的“格调”
就像书中所说：成功地运行并不能保证一个程序的优良。在编写代码的过程中，除了实现规定的功能之外，代码规范也无处不在，包括：1)程序布局是否工整；2)变量命名是否规范；3)代码注释是否简明；4)函数封装是否合理；5)程序接口是否恰当；6)实现方法是否正确；等等。所有这些规范和约束，都是为了提高程序的“格调”。
代码编写完成，开发人员的事情并没有完成，他们还需要对自己的代码进行测试，即自测。充分的自测可以发现代码在逻辑、功能等上面的一些错误，并纠正开发人员一些思维的缺陷。这也是在提高程序的“格调”。

时光荏苒，《编程格调》一书虽作于将近40年之前，但其中的很多观点在今天仍然具有很强的参考价值，里面的很多程序编写的经验仍然值得广大的IT从业人员学习。如果我们静下心来阅读，定然会被作者对于程序编写的洞见所折服，这也反过来提高了我们思维的“格调”。
不管你是即将踏上工作岗位的在校学生，还是刚参加工作的职场新人，抑或是有多年工作经验的职场老人，只要大家关注编程、关注软件开发，那么我都毫不犹豫地推荐你阅读《编程格调》一书。
最后，感谢高博老师的慷慨赠书，让我开启了如此美妙的一段阅读之旅！

一本老书,两个牛人,一堆经验

胖胖的大头鱼 2006-10-02 6

一本老书,写书的两个牛人.
Brian W. Kernighan,熟悉unix/c语言的没有不知道他老人家的大名的,文字漂亮,技术厉害.
P. J. Plauger,这位仁兄是为ms提供stl实现的公司头头(不过jjHou说那是可读性最差的一份stl实现,哈哈), 他很早就在c++里面混了,似乎是CUJ的高级编辑.
不过这本书全是fortran code,一堆堆的goto语句,真的是时代不同了,看代码基本不知道在干什么.
其中总结的rules倒是永恒的真理,今天来看也一点不过时,今天书市上所谓的教程序风格的书,不过是炒炒陈饭而已:)

一本老书，值得你啃

vinurs 2013-01-20 3

这是一本关于计算机编程风格的老书，就算只看最后的SUMMARY OF RULES都会觉得对你有所启发！
最好能通读这本书，结合书中的实例来理解那些RULES，你会知道什么是一种优秀的习惯，如果能将书中总结的RULES运用到实际编程中去，虽然不能让你成为一个优秀的程序员，但是会给你启发，让你通往优秀的程序员之路。
写出机器能看懂的程序很容易，写出人看懂的程序就不容易了！

读读Rules还是不错的

wuyve 2014-04-21 1

没研究过此书中代码所使用的Fortan和PL/I这两种语言，不过之前读过诸如Writing Solid Code、The Practice of Programming、编程珠玑一类的书，发现它们的Tips都是很类似的，比如：可读性、模块化、防御性编程、浮点计算和判等、数据结构决定程序、测试，等等。此书不知是不是编程建议类书籍的滥觞。
个人认为如果不是这两种语言的使用者，并且不打算为读这本书而专门学习，但具有其他语言的编程经验和类似书籍的阅读体验，此书速读一下Rules足矣。这大概也是在网上搜索此书经常发现是一份3页的Rules合集的原因。当然，读的时候应该联想之前的编程经验才能有所体会。
不过对于“Avoid temporary variables”这一条存疑。此书的示例中F1和F2仅仅是保存了两个中间结果，我认为在两种情况下，还是应该使用临时变量的：
1.具有实际意义，增加可读性——不过此时似乎又不应该仅仅是临时变量了；
2.(如在C中)将一个常用的变量放入寄存器中，避免多次进行存储器引用或函数调用，实例可见于《深入理解计算机系统》(CS:APP)图5-6。

软件开发中的“格调”

周兆熊 2015-04-07 1

在三年之前，我从学校毕业，进入公司，正式开始了软件开发工作。我从完成第一个开发任务的过程中学到了很多东西，包括：1)编写程序只是软件开发中的一个流程，并非全部；2)程序编写需要遵循一定的规范，远远不只是实现功能那么简单；3)程序编写者是程序的第一负责人，要对自己的程序进行充分的自测，而非只要程序编写完成便万事大吉了。大家在学校里面也编写过程序，但那并非规范的软件开发活动。从学校里面的“业余”进化为正式工作岗位上的“专业”，就需要提升我们的“编程格调”。
什么是“格调”？韦庄在《送李秀才归荆溪》的诗中曰：“人言格调胜玄度，我爱篇章敌浪仙。”对于一篇文章来说，“格调”是指文章的风格；而对于编程来说，“格调”是指程序的风格、样式。那么，什么是好的“编程格调”？《编程格调》一书为我们带来了答案。
本书的两位作者Brian W. Kernighan和P.J. Plauger是全球知名的计算机科学家，Brian W. Kernighan更是一位德高望重的计算机先驱，他与“C语言之父” Dennis Ritchie合著了经典书籍《The C Programming Language》。本书的译者之一高博老师也是“文津图书奖”译者(他所翻译的《信息简史》获得了“文津图书奖”)。如此一来，本书也已成经典。
本书篇幅不长，包括8个章节、共180页的内容，从表达、控制结构、程序结构、输入和输出、常见错误、效率和测试工具、文档等方面对“编程格调”展开了讨论。对于一些优秀的编程经验，本书提炼了出来，并放在了方框里面，以供读者参考。
我认为，对于一位开发人员来说，在软件开发中的“编程格调”体现在这三方面：第一，编程意识的“格调”；第二，程序设计的“格调”；第三，代码编写及测试的“格调”。

编程意识的“格调”
代码是程序员思维的体现，你在脑海里构思出怎样的程序，你就会编写出怎样的程序。因此，如果一个程序员没有要编写出优秀程序的意识，那么他们实际编写出来的程序也不会好到哪里去。
为了让自己的程序有“格调”，我们首先要在意识上严格要求自己，要提高自己的思维的水准。如此这般，才能够将意识的“格调”转变为程序的“格调”。

程序设计的“格调”
在动手编写代码之前，我们要对程序流程进行设计，也就是对程序进行宏观布局。
看过《三国演义》的人都知道，诸葛亮很善于宏观布局。在三国尚未形成之时，他就分析了当下局势，并为刘备指明了夺取天下的战略方针。在一场大战役打响之前，诸葛亮会分析天时和地利，并告诉各个将领一些排兵布阵的方法。他就是战争的总指挥，我们可以说他在战略上很有“格调”。
程序设计也与之类似。我们要分析软件需求，看哪些功能比较容易实现，哪些比较复杂。在弄懂了需求之后，我们要画出程序流程图及模块框架，并决定哪些模块可以采用现成的，哪些需要新开发，哪些功能要先实现，哪些可以后面再完成。只有有“格调”的设计才能够产生有“格调”的程序。

代码编写及测试的“格调”
就像书中所说：成功地运行并不能保证一个程序的优良。在编写代码的过程中，除了实现规定的功能之外，代码规范也无处不在，包括：1)程序布局是否工整；2)变量命名是否规范；3)代码注释是否简明；4)函数封装是否合理；5)程序接口是否恰当；6)实现方法是否正确；等等。所有这些规范和约束，都是为了提高程序的“格调”。
代码编写完成，开发人员的事情并没有完成，他们还需要对自己的代码进行测试，即自测。充分的自测可以发现代码在逻辑、功能等上面的一些错误，并纠正开发人员一些思维的缺陷。这也是在提高程序的“格调”。

时光荏苒，《编程格调》一书虽作于将近40年之前，但其中的很多观点在今天仍然具有很强的参考价值，里面的很多程序编写的经验仍然值得广大的IT从业人员学习。如果我们静下心来阅读，定然会被作者对于程序编写的洞见所折服，这也反过来提高了我们思维的“格调”。
不管你是即将踏上工作岗位的在校学生，还是刚参加工作的职场新人，抑或是有多年工作经验的职场老人，只要大家关注编程、关注软件开发，那么我都毫不犹豫地推荐你阅读《编程格调》一书。
最后，感谢高博老师的慷慨赠书，让我开启了如此美妙的一段阅读之旅！

编程格调总结

萬軍 2015-07-05 0

一、表达
  1.写清楚
  2.保守使用临时变量
  3.明白无歧义
  4.不要自己造所有的工具
  5.确保判断测试条件清楚易读

二、控制结构
  1.先用你顺手的高级语言写一遍程序，这时可以看清楚算法并作相应的调试，程序正确之后，再翻译成你编译器所处理的语言
  2.子例程和函数，把代码分成可独立管理的小段
  3.规划数据结构的时候要像规划控制流一样小心，尝试找到可以起到简化程序作用的数据表示形式

三、程序结构
  1.编写和维护大型程序唯一的方法是把它分解成一组函数、子例程和过程
  2.每一个模块应该只处理问题的一个方面，否则的话，模块就会变得大而复杂
  3.相对于其他模块，一个模块应该隐藏它如何完成工作的细节，否则这个模块就无法独立于其他模块来进行修改

四、输入和输出
  1.校验输入数据的合法于合理性
  2.保证输入数据不会违背程序的限制
  3.利用文件结束符号或结束标志来终止输入，不要让用户去计数
  4.识别输入错误并尽可能地恢复，不要一碰到错误就停止，也不要忽略错误了事
  5.在输入和输出时采用助记符，使得输入数据易于正确地准备，在输出时同时也將输入和默认值输出，并使得输出数据不言自明
  6.將I/O局限起来，不要散布在整个程序中。將处理文件结束和缓冲区等细节隐藏在函数中
  7.保证程序的结构反映出其所处理的数据

五、常见错误
  1.使用变量之前要初始化
  2.小心"差一"错误，确保在正确的次数下完成循环，对于等式的比较判断，确保有正确的分支处理
  3.检查数组的下标不要越界
  4.避免循环有多个出口
  5.检查程序的内部边界
  6.预防性编程，搞清楚哪些事可能出问题，并且添加代码以检查
  7.不要用浮点数来做累计，不要期望浮点小数数值遵循你熟悉的算术法则，他们不适用

六、效率和测试工具
  1.假如程序是错误的，再快也没用。
  2.让代码言简意赅。撰写时不要惦记着它运行得快。过早优化是万恶之源
  3.别为每个优化细节去操心，让编译器去照顾这些
  4.用心于算法，而非代码细节。记住，数据结构对算法的实现方式有显著影响
  5.在构造程序时放置测试语句，在决定"增效"之前先执行测试。在程序演进过程中，可將测试语句留下来随时运用

七、文档
  1.如果程序不正确，文档写得再好都没有用
  2.如果文档和代码不一致，那程序就没什么价值
  3.要在最大程度上使得代码本身就是自己的文档，如果做不到，重写代码而不是做文档的补充。好的代码需要的注释量要比坏的代码少
  4.注释提供的信息应该是从代码上无法获得的
  5.帮助记忆的变量名和标签，以及强调逻辑结构的代码布局，都有助于程序自身的文档化

石器时代的语言和规范

游侠Harry 2017-01-09 0

看这本书之前，我刚刚写了一个最原始的BASIC语言解释器作为Parser的练手项目。完成后，用了这个解释器试运行了经典的月球登陆车游戏，顺便分析了游戏的源代码，发现读起来各种不便

1. IF语句只能指定跳转行号，不支持ELSE
2. 只能用IF和GOTO来模拟WHILE循环
3. 没有函数调用，只能用GOSUB和RETURN来模拟子过程，阅读的时候为了找到RETURN回到哪得反复查半天。

当时我觉得这只是因为BASIC语言仅仅是给初学者当玩具用的语言，所以才这么难以阅读。

但接下来我就看了这本书，发现1和2在书中的FORTRAN语言也是存在的，因此，两位先贤花费了大量篇幅教导石器时代的开发者，要用条件和循环等分支结构，尽量的少用GOTO等等。并给出了一系列的规范。

但当支持结构式良好的编程语言PASCAL和C出现后，很多书中的规范已经成为自然而然的了。看来，这也是PASCAL和C迅速抢占市场的原因之一（后来C语言因为更贴近机器模型而打败了PASCAL，这是另外一个故事）。

看了这些石器时代的工具，想起来有位大牛说过“设计模式的存在都是为了弥补语言特性的缺陷”。

秦人（FORTRAN, BASIC）无暇自哀，而后人哀之；后人（C++，Java）哀之而不鉴之，以示后人复哀后人也。

我要写长评

想读在读读过

标签(多个标签以“，”分开):

保存

The Elements of Programming Style, 2nd Edition

推荐文章

猜你喜欢

附近的人在看

推荐阅读

拓展阅读