编程格调

出版者:人民邮电出版社

作者:[美] Brian W. Kernighan

页数:180

译者:高博

出版时间:2015-3

价格:49

装帧:平装

isbn号码:9787115379528

具体描述

《编程格调》是编程惯用法和规则的实践指南。全书从表达、控制结构、程序结构、输入和输出、常见错误、效率和测试工具、文档等多个角度，概括了程序设计中若干的最佳实践或规则，并通过代码示例加以分析和阐释。

本书两位作者都是程序设计领域的大师级任务。他们四十年前在本书中给出的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公司高级系统管理工程师，从事软件运维工作多年，钟爱开源软件。对各类知识有广泛兴趣，平日喜爱参与问答网站讨论，热爱读书摄影和写作。

目录信息

第1章　绪论 1
撰写简洁的程序—不要耍小聪明 2
第2章　表达 13
简单并且直接地表达你要说的意思 14
使用库函数 14
避免使用临时变量 16
代码要清晰，不要为了“效率”牺牲可读性 16
让机器干脏活 17
用函数调用替代重复的表达式 18
加括号来避免歧义 21
选择不会被混淆的变量名 21
避免使用Fortran的算术IF 23
避免不必要的分支 25
使用语言好的特性，避免使用不好的特性 25
不要使用条件分支来代替一个逻辑表达式 26
用“电话测试”来检查可读性 29
第3章　控制结构 39
使用DO-END和缩进来界定语句组 40
用IF-ELSE强调两个操作中只有一个被执行 42
用DO和DO-WHILE来强调循环的存在 45
确保你的程序是自顶向下阅读的 46
使用IF…ELSE IF…ELSE IF…ELSE 来实现多路分支 47
使用基本的控制流结构 48
先用容易理解的伪语言编写代码，然后再翻译成 你需要使用的语言 52
避免使用THEN-IF和空ELSE 55
避免使用ELSE GOTO和ELSE RETURN 56
判断要尽可能紧挨着与之相关的操作 58
使用数组来避免重复的控制流 61
选择可以简化程序的数据表示方法 63
不要止步于第一遍的代码草稿 66
第4章　程序结构 71
模块化，使用子例程 74
让模块之间的耦合变得可见 75
每一个模块都应该做好一件事 76
确保每一个模块都隐藏好一些东西 78
以数据为导向来构建程序的结构 80
不要修补烂代码——重写它 84
分块编写和测试大的程序 91
对于递归定义的数据结构使用递归过程 91
第5章　输入和输出 97
校验输入的合法性和合理性 100
保证输入数据不会违背程序的限制 101
利用文件结束符号或结束标志来终止输入， 不要让用户去计数 102
识别出非法输入数据，如果可能则纠正之 103
使用统一的形式处理文件结束条件 105
让输入数据易于准备，并让输出数据意义不言自明 108
使用统一的输入格式 110
让输入数据易于校对 111
尽可能选择自由格式输入 112
使用含义自明的输入，指定默认值，将以上二者都输出 112
将输入与输出局限在子例程中 116
第6章　常见错误 119
确保所有的变量在使用之前都被初始化 120
不要停留在一个bug上 122
使用调试编译器 124
用DATA语句或INITIAL属性初始化常量， 用可执行语句初始化变量 125
小心“差一”错误 126
要注意对不等式进行正确的分支 126
避免循环有多个出口 128
确保你的代码巧妙地“不做事情” 131
在边界值上测试程序 135
预防性编程 136
10.0乘以0.1不等于1.0 137
不要比较浮点数是否相等 139
第7章　效率和测试工具 145
先做对，再做快 147
在提高程序运行速度时，要保持其正确性 149
先把程序改得更简洁，再提高其运行速度 150
不要为了“效率”上的蝇头小利而牺牲程序的简洁性 151
让编译器执行平凡优化 151
不要勉强地复用代码，应该进行改编 152
保证特殊情况真的有特殊性 155
保持简单性，反而会更快 157
不要为了提高速度而画蛇添足—去寻找更好的算法 159
在程序中放置测试语句，“增效”之前先执行测算 161
第8章　文档 165
确保注释和代码一致 167
不要用注释复述代码做的事情， 每个注释都要有实际意义 167
不要注释糟糕的代码——重写它 169
使用含有意义的变量名 170
使用含有意义的语句标签 171
程序的格式要有助于读者的理解 171
用缩进来体现程序的逻辑结构 172
记录你的数据规划 175
不要过度注释 176
结束语 180
· · · · · · (收起)

读后感

没研究过此书中代码所使用的Fortan和PL/I这两种语言，不过之前读过诸如Writing Solid Code、The Practice of Programming、编程珠玑一类的书，发现它们的Tips都是很类似的，比如：可读性、模块化、防御性编程、浮点计算和判等、数据结构决定程序、测试，等等。此书不知是不是编...  

没研究过此书中代码所使用的Fortan和PL/I这两种语言，不过之前读过诸如Writing Solid Code、The Practice of Programming、编程珠玑一类的书，发现它们的Tips都是很类似的，比如：可读性、模块化、防御性编程、浮点计算和判等、数据结构决定程序、测试，等等。此书不知是不是编...  

在三年之前，我从学校毕业，进入公司，正式开始了软件开发工作。我从完成第一个开发任务的过程中学到了很多东西，包括：1)编写程序只是软件开发中的一个流程，并非全部；2)程序编写需要遵循一定的规范，远远不只是实现功能那么简单；3)程序编写者是程序的第一负责人，要对自己...  

没研究过此书中代码所使用的Fortan和PL/I这两种语言，不过之前读过诸如Writing Solid Code、The Practice of Programming、编程珠玑一类的书，发现它们的Tips都是很类似的，比如：可读性、模块化、防御性编程、浮点计算和判等、数据结构决定程序、测试，等等。此书不知是不是编...  

在三年之前，我从学校毕业，进入公司，正式开始了软件开发工作。我从完成第一个开发任务的过程中学到了很多东西，包括：1)编写程序只是软件开发中的一个流程，并非全部；2)程序编写需要遵循一定的规范，远远不只是实现功能那么简单；3)程序编写者是程序的第一负责人，要对自己...  

用户评价

我作为一个刚从校园步入职场的萌新，面对堆积如山的技术栈感到无从下手。我之前看的书大多是技术手册，告诉你“怎么做”，但很少有人告诉我“为什么这么做”背后的深层思考逻辑。这本书的叙事方式非常独特，它更像是一系列精彩的“编程哲学小故事”，通过对历史上的经典设计模式的溯源和现代应用场景的对比，构建了一种强大的思维框架。举例来说，它解析了函数式编程范式和面向对象范式在解决特定类型问题时的优劣权衡，不是非黑即白地推崇某一种，而是教会读者根据**情境**来选择最合适的“工具箱”。让我印象深刻的是，书中对“简化”的追求达到了偏执的程度。作者反复强调，最复杂的系统往往源于对简单概念的过度堆砌，而真正的“格调”体现在如何用最少的代码和最清晰的结构，解决最复杂的问题。这种对**优雅**的追求，让我对未来的职业发展有了一个全新的认识：编程不仅仅是解决问题，更是一种表达和沟通的艺术。

我是一个长期负责大型分布式系统架构的资深工程师，说实话，市面上大部分架构书籍都充斥着对微服务、容器化这些时髦词汇的简单罗列。然而，这本著作的视角却高屋建瓴且深邃无比。它没有纠缠于具体的中间件版本（这部分内容过时得太快了），而是聚焦于那些亘古不变的挑战：**一致性、容错性和扩展性**的本质。它用清晰的数学逻辑和系统论的视角，将复杂的分布式难题还原为几个核心的权衡点。我特别欣赏它对**局部最优陷阱**的剖析——很多团队为了局部性能的提升，牺牲了整体系统的可理解性和扩展性，最终导致系统陷入僵局。书中提供了一个“系统健康度”的评估模型，这个模型非常实用，它可以帮助架构师定期自检，判断系统是处于“健康成长”还是“病态膨胀”的状态。对于那些想从“实现者”跃升为“设计者”的同行们，这本书提供的思考深度是无价的。

这本书的语言风格简直就是一股清流，完全没有传统技术书籍那种刻板和干燥。阅读体验极其顺畅，仿佛不是在啃一本技术书，而是在听一位极富幽默感和洞察力的前辈分享他的“踩坑血泪史”。它最大的价值在于，它成功地捕捉到了“个体开发者”在面对企业级项目时的那种心理挣扎和技术抉择的困境。比如，当团队内出现“英雄式编程”的倾向时，作者如何用幽默又尖锐的笔触，揭示了这种短期效率背后的巨大风险。书中关于**“自动化与手工的黄金分割点”**的讨论非常到位，它没有盲目鼓吹一切都要自动化，而是清晰地指出了哪些流程的自动化能带来指数级回报，而哪些流程强行自动化只会增加维护成本。我经常在遇到技术瓶颈时，随手翻开其中一章，总能从中获得一种被理解的释然和解决问题的全新角度。

这本关于现代软件开发的指导手册，简直就是为我这种在代码海洋里摸爬滚打多年的“老兵”量身定制的。它没有落入那种空泛的理论说教，而是像一位经验丰富的导师，直接将我们带到项目攻坚的最前线。最让我眼前一亮的是，它对“可维护性”这个抽象概念进行了极其细致的拆解和量化。作者似乎深谙，代码一旦写完，就进入了维护的漫长生命周期，所以书中花了大量篇幅讨论如何通过精妙的命名、恰到好处的抽象层次，以及前瞻性的错误处理机制，来构建一个“活下去”的系统。特别是关于“技术债务”的处理策略，不再是简单地喊口号让大家“重构”，而是提供了一套实用的优先级排序和渐进式清理的路线图，甚至给出了如何在商业压力下，与非技术团队有效沟通技术投入回报率的实战技巧。读完后，我立刻在团队内部推行了书中提到的代码审查（Code Review）新范式，效果立竿见影，团队的整体代码质量和协作效率都有了质的飞跃。这本书不是教你如何快速写出能跑的代码，而是教你如何写出能被“人”读懂、能被“时间”考验的代码。

从一个对代码质量有着近乎苛刻要求的审稿人角度来看，这本书的深度和广度都令人叹服。它不仅仅停留在“代码规范”的层面，而是深入探讨了**“编程的伦理”**。这听起来有些宏大，但书中将这种伦理具体化了：对未来读者的尊重，对用户数据处理的审慎，以及对技术边界的清晰认知。书中对“过早优化”的批判，不是简单地反对性能调优，而是将其置于整个软件生命周期的视角下进行评估，指出在需求未明确时进行深度优化，其成本远远高于收益。此外，书中对测试驱动开发（TDD）的讨论也极富启发性，它将其视为一种“契约精神”的实践，而非仅仅是写测试用例的流程。这本书的布局结构极其严谨，每一章的论证都像是在构建一座逻辑严密的建筑，让人不得不佩服作者在信息组织和逻辑递进上的高超能力。

语言使用fortran 有点过时

C语言创始人怎么不用C来写example，书里面的tip也都是老生长谈，现在看没啥意思，也有一些东西都过时了

精辟，就是fortran看着脑仁疼，还有那个年代还在跟goto斗争，看着满篇的如何消除goto的介绍也是醉了

原著书名为 The Elements of of Programming Style, 胆敢取名 elements 的书还可以一版再版的，都牛得不得了，比如《几何原本》。此书与《几何原本》从几条简单原理推导出整个世界类似，给出若干来自实践的原则和原则应用的案例，如何应用还得你我在实践中参详，像习题集。对于计算机专业短短的历史，这些原则非常古老，书成于FORTRAN流行的时代。但是真正本质的原则往往从行业诞生之日就隐约存在，并不需世事变迁而有所损益，只是等待时间雕琢慢慢让它们清晰起来。比如C语言的成功并不像课本前言中写得那么轻易和简单，超越同时代诸多竞争语言赢得声名和后继影响决非偶然。本书作者之一即是C语言和UNIX创造者之一。

是也乎 ╮(╯▽╰)╭ 虽然用 fortran PL/I 来展示案例… 但是思想依然相通…甚至是其中有的直接变成了新语言的特性… 比如 python 和 golang 都将缩进当成了程序本身的语法要求… 更可贵的是: 字体用了原版代码的… 审稿人都是业界老司机… 总之经典首先得是薄薄小书…然后才是穿越时空而不损其意~