出版社: 电子工业出版社
出品方: 博文视点
原作名: Code Complete
译者: 金戈 / 汤凌 / 陈硕 / 张菲 译 / 裘宗燕 审校
出版年: 2006-3
页数: 944
定价: 128.00元
装帧: 平装
丛书: 博文视点·传世经典书丛
ISBN: 9787121022982
内容简介 · · · · · ·
第2版的《代码大全》是著名IT畅销书作者史蒂夫·迈克康奈尔11年前的经典著作的全新演绎:第2版不是第一版的简单修订增补,而是完全进行了重写;增加了很多与时俱进的内容。这也是一本完整的软件构建手册,涵盖了软件构建过程中的所有细节。它从软件质量和编程思想等方面论述了软件构建的各个问题,并详细论述了紧跟潮流的新技术、高屋建瓴的观点、通用的概念,还含有丰富而典型的程序示例。这本书中所论述的技术不仅填补了初级与高级编程技术之间的空白,而且也为程序员们提供了一个有关编程技巧的信息来源。这本书对经验丰富的程序员、技术带头人、自学的程序员及几乎不懂太多编程技巧的学生们都是大有裨益的。可以说,无论是什么背景的读者,阅读这本书都有助于在更短的时间内、更容易地写出更好的程序。
作者简介 · · · · · ·
史蒂夫·迈克康奈尔(Steve McConnell)被公认为软件开发社区中的首要作者和发言人之一。他是Construx Software公司的首席软件工程师。他所编著的图书包括曾被《软件开发》杂志授予优异产品震撼大奖的《代码大全》和《快速软件开发》,以及《软件项目生存指南》和《专业软件开发》等等。
目录 · · · · · ·
第 2 章 用隐喻来更充分地理解软件开发 9
第 3 章 三思而后行:前期准备 23
第 4 章 关键的“构建”决策 61
第 5 章 软件构建中的设计 73
第 6 章 可以工作的类 125
· · · · · · (更多)
第 2 章 用隐喻来更充分地理解软件开发 9
第 3 章 三思而后行:前期准备 23
第 4 章 关键的“构建”决策 61
第 5 章 软件构建中的设计 73
第 6 章 可以工作的类 125
第 7 章 高质量的子程序 161
第 8 章 防御式编程 187
第 9 章 伪代码编程过程 215
第 10 章 使用变量的一般事项 237
第 11 章 变量名的力量 259
第 12 章 基本数据类型 291
第 13 章 不常见的数据类型 319
第 14 章 组织直线型代码 347
第 15 章 使用条件语句 355
第 16 章 控制循环 367
第 17 章 不常见的控制结构 391
第 18 章 表驱动法 411
第 19 章 一般控制问题 431
第 20 章 软件质量概述 463
第 21 章 协同构建 479
第 22 章 开发者测试 499
第 23 章 调试 535
第 24 章 重构 563
第 25 章 代码调整策略 587
第 26 章 代码调整技术 609
第 27 章 程序规模对构建的影响 649
第 28 章 管理构建 661
第 29 章 集成 689
第 30 章 编程工具 709
第 31 章 布局与风格 729
第 32 章 自说明代码 777
第 33 章 个人性格 819
第 34 章 软件工艺的话题 837
第 35 章 何处有更多信息 855
参考文献 863
索引 883
· · · · · · (收起)
"代码大全(第2版)"试读 · · · · · ·
CodeGear首席技术官(CTO) 李维——代码大全是我早在好几年前便已经阅读过的好书。这几年来我不知买过多少书籍,也清理过许多因为书房再也放不下的书籍,但是代码大全这本书始终占据着我书架上重要的位置而不曾移开过,因为好书是经得起时光考验的。 微软亚洲研究院 研究员 潘爱民——在众多的编程类书籍中,如果只让我挑一本书来阅读,那我一定选择《代码大全》,因为它是最不可或缺的..
原文摘录 · · · · · · ( 全部 )
-
设计是一个启发式过程 隐喻是启示而不是算法 典型情况下需求会有多少改动?IBM和其他公司的研究发现,平均水平的项目在开发过程中,需求会有25%的变化(Boehm 1981,Jones 1994,Jones 2000)。在典型的项目中,需求变更导致的返工占到返工总量的75%到85%(Leffingwell 1997,Wiegers 2003)。 注意项目的商业案例:有些需求作为功能特色来看是不错的想法,但是当你评估“增加的商业价值”时就会觉得它是个糟透了的主意。 一个好的项目规划者,应能尽早清楚项目中的主要风险,以使大部分工作能平稳进行。 (查看原文) —— 引自章节:全书文摘 -
发现错误要尽可能接近引入错误的时间,缺陷在软件食物链里面呆的时间越长,它对食物链的后级造成的损害就越严重 “问题定义”只定义了“问题是什么”,而不涉及任何可能的解决方案,应在需求分析之前,而需求分析是对所定义问题的深入调查,应该用客户语言来写,从客户角度来描述问题 (查看原文) —— 引自章节:全书文摘
> 全部原文摘录
丛书信息
喜欢读"代码大全(第2版)"的人也喜欢的电子书 · · · · · ·
喜欢读"代码大全(第2版)"的人也喜欢 · · · · · ·
代码大全(第2版)的书评 · · · · · · ( 全部 122 条 )

OOM 时代更珍贵了
-
开着douban.fm,用思维导图XMind写《Code Complete》( 《代码大全2》 )的读书笔记,用Dropbox git做版本管理,用RTM([https://www.rememberthemilk.com])做GTD(Get Things Done),计划把860页的《代码大全2》读完,并做一个完整的软件构建笔记与大家分享:)。 xmind笔记放在[https://github.com/philsong/codecomplete2] 我的读书计划[http://jihua.fm/users/104020]
2012-03-17 07:50:49 14人喜欢
开着douban.fm,用思维导图XMind写《Code Complete》( 《代码大全2》 )的读书笔记,用Dropbox git做版本管理,用RTM(https://www.rememberthemilk.com)做GTD(Get Things Done),计划把860页的《代码大全2》读完,并做一个完整的软件构建笔记与大家分享:)。 xmind笔记放在https://github.com/philsong/codecomplete2 我的读书计划http://jihua.fm/users/104020
回应 2012-03-17 07:50:49 -
Suave (trust instinct, be visionary)
设计是一个启发式过程 隐喻是启示而不是算法 典型情况下需求会有多少改动?IBM和其他公司的研究发现,平均水平的项目在开发过程中,需求会有25%的变化(Boehm 1981,Jones 1994,Jones 2000)。在典型的项目中,需求变更导致的返工占到返工总量的75%到85%(Leffingwell 1997,Wiegers 2003)。 注意项目的商业案例:有些需求作为功能特色来看是不错的想法,但是当你评估“增加的商业价值”时就会觉得它是个糟透了的主意。 一个...2012-02-14 14:09:08 8人喜欢
设计是一个启发式过程 隐喻是启示而不是算法 典型情况下需求会有多少改动?IBM和其他公司的研究发现,平均水平的项目在开发过程中,需求会有25%的变化(Boehm 1981,Jones 1994,Jones 2000)。在典型的项目中,需求变更导致的返工占到返工总量的75%到85%(Leffingwell 1997,Wiegers 2003)。 注意项目的商业案例:有些需求作为功能特色来看是不错的想法,但是当你评估“增加的商业价值”时就会觉得它是个糟透了的主意。 一个好的项目规划者,应能尽早清楚项目中的主要风险,以使大部分工作能平稳进行。 引自 全书文摘 这通常包含两方面的工作:1. 分析出全面准确的需求;2.创建高质量的架构
发现错误要尽可能接近引入错误的时间,缺陷在软件食物链里面呆的时间越长,它对食物链的后级造成的损害就越严重 “问题定义”只定义了“问题是什么”,而不涉及任何可能的解决方案,应在需求分析之前,而需求分析是对所定义问题的深入调查,应该用客户语言来写,从客户角度来描述问题 引自 全书文摘 值得反复阅读的: 1. ch3.5 结构的典型组成部分,后面还有一个checklist,是架构师应该认真理解的。架构也不但是架构师的工作,每个参与项目的程序员都应该把自己看作架构师,站在全局的角度上理解项目
Sapir-Whorf假说是,你思考的能力取决于你是否知道能够表达该思想的词汇。如果你不知道这些词汇,就无法表达出这种思想,甚至可能不能形成这种思想(Whorf 1956)。 引自 全书文摘 回应 2012-02-14 14:09:08 -
Suave (trust instinct, be visionary)
“险恶的(wicked)”问题就是那种只有通过解决或部分解决才能被明确的问题(1973)。这个看似矛盾的定义其实是在暗示说,你必须首先把这个问题“解决”一遍以便能够明确地定义它,然后再次解决该问题,从而形成一个可执行的方案。这一过程已经如影随形地在软件开发中存在数十年了(Peters and Tripp 1976) 的确,如何全面的分析所面对的问题是最棘手的事情。面对所要构建的系统,我更推荐先仔细查找、分析你所能找到的所有类型系统... (1回应)2012-05-07 13:37:01 5人喜欢
“险恶的(wicked)”问题就是那种只有通过解决或部分解决才能被明确的问题(1973)。这个看似矛盾的定义其实是在暗示说,你必须首先把这个问题“解决”一遍以便能够明确地定义它,然后再次解决该问题,从而形成一个可执行的方案。这一过程已经如影随形地在软件开发中存在数十年了(Peters and Tripp 1976) 引自 5.1 Design is a WICKED problem 的确,如何全面的分析所面对的问题是最棘手的事情。面对所要构建的系统,我更推荐先仔细查找、分析你所能找到的所有类型系统、设计、代码。经验标明,系统中的80%的部分应该能找到参照系,这也是 80/20 原则。在这样的指导建议下,能很大程度上降低设计的难度和风险
1回应 2012-05-07 13:37:01 -
coco+ (程序猿出没)
1.表驱动法: 从表里查找信息而不是使用逻辑语句(if 和 else),用直接访问代替复杂的逻辑控制结构,例如字符分类,月中的天数和保险费。 2.如果有多种不同的消息,而且这些消息可能改变,可能增加,最好使用表驱动法,因为你不得不为每一种消息建立函数或类,如果里面的数据类型改变,你甚至要改变程序逻辑。而使用表驱动,只需要编写少量的代码就可以完成任务。 3.构造查询键值。有时候并不能直接拿数据作为键值直接访问表,...2014-10-28 22:29:02 1人喜欢
1.表驱动法: 从表里查找信息而不是使用逻辑语句(if 和 else),用直接访问代替复杂的逻辑控制结构,例如字符分类,月中的天数和保险费。 2.如果有多种不同的消息,而且这些消息可能改变,可能增加,最好使用表驱动法,因为你不得不为每一种消息建立函数或类,如果里面的数据类型改变,你甚至要改变程序逻辑。而使用表驱动,只需要编写少量的代码就可以完成任务。 3.构造查询键值。有时候并不能直接拿数据作为键值直接访问表,例如年龄(为不满18岁者设置一个费率)。 (1)复制信息从而直接使用键值。例如为18岁以下的每个年龄赋值一份费率 (2)转换键值,让他们直接使用。将age转换为另一个数值,例如把0-17岁的人都转换成17.用max(age)就成。但使用这种方法,数据得有一定的模式 (3)把键值转换提取成独立的子程序。例如hash function 4.索引访问表。当只用一个简单的数学计算无法把数据转换成表键值时使用,先用一个基本类型的数据从一张索引表中查出一个键值,然后再用这一键值查出主数据,例如商品编号范围为0-9999,但你店里只有100种商品,就可以建立索引表。 (1)优点一,节省空间,如果主查询表里的每一条记录都很大,那么建立索引表的代价就小很多。 (2)优点二,方便廉价,操作索引表的记录比操作主表中的记录更方便廉价。例如含有员工姓名,雇佣日期和薪水的表,可以分别生成一个索引表访问该表。 (3)优点三,维护起来很方便,编写在表里的数据比嵌入代码中的数据更容易维护。可以将索引访问数据的代码提取成单独的子程序,以后修改起来也方便。 5.阶梯访问表,针对无规则分布的数据,例如键值是浮点数。表中的记录对不同的数据范围有效而不是对不同的数据点。把每一区间的上限写入表中,当分数第一次超过某个区间的上限时,你就知道相应的等级了。 注意点: (1)留心端点:正确处理区间边界,不要把<误用为<=。 (2)考虑用二分查找代替顺序查找。 (3)可以考虑用索引访问代替阶梯结束。阶梯访问可能比较耗时,可以牺牲存储空间来换取速度。在可以建立索引的情况下使用,例如只有100个分值,但对于浮点数还是算了。 (4)把阶梯表查询提取成单独的子程序
回应 2014-10-28 22:29:02
-
代码大全 3.1.2 在进行创建工作之前必须做准备工作的论据 2013-01-06 08:26:42 在一个正常的生态系统中,海鸥以沙丁鱼为食,沙丁鱼吃鲜鱼,鲜鱼吃水虱,其结果会形成一个正常的食物链。在编程工作中,如果软件食物链的每一级都可以吃到健康的食物,其结果是由一群快乐的程序员写出的正确代码。 2013-01-06 08:27:17 如果需求定义遭受了污染,那么这又会影响结构设计,而这将最终影响创建活动。这将导致程序员们脾气暴躁而营养不...
2013-01-08 21:22:05 1人喜欢
代码大全 3.1.2 在进行创建工作之前必须做准备工作的论据 2013-01-06 08:26:42 在一个正常的生态系统中,海鸥以沙丁鱼为食,沙丁鱼吃鲜鱼,鲜鱼吃水虱,其结果会形成一个正常的食物链。在编程工作中,如果软件食物链的每一级都可以吃到健康的食物,其结果是由一群快乐的程序员写出的正确代码。 2013-01-06 08:27:17 如果需求定义遭受了污染,那么这又会影响结构设计,而这将最终影响创建活动。这将导致程序员们脾气暴躁而营养不良,同时生产出遭受严重污染而充满缺陷的软件。 3.3.1 为什么要有正式的需求 2013-01-06 08:27:37 问题定义只描述要解决的问题是什么,根本不涉及解决方法。它应该是一个简短的说明, 听起来像一个问题。比如“我们无法跟上指令系统”听起来像一个问题,也是一个好的问题定义。而“我们需要优化数据入口系统以便跟上指令系统”则是一个糟糕的问题定义,它听起来不像是个问题而更像是个解决方案。 2013-01-06 08:24:47 明确的需求可以保证是由用户而不是程序员决定系统的功能。 3.3.3 在创建阶段如何对付需求变化 2013-01-06 10:31:54 正如随着工作的进行,你对其理解越来越深刻一样,用户对自己想要的东西,也是随着项目的进行而越来越清楚的,这也是需求变动的主要原因。-个从不变更需求的计划,事实上是一个对用户的需求不予理睬的计划。 典型的变动有多少呢?根据 IBM 的调查,对于一个典型的有一百万 3.3.4 检查表 2013-01-06 10:32:54 让每个人都知道由于变化需求所付出的代价 2013-01-06 10:33:55 建立一套更改控制过程 13.1 必须有明确顺序的程序语句 2013-01-06 11:11:47 使用子程序参数使依赖关系明显。 13.2.3 使变量存活时间尽可能短 2013-01-06 11:12:37 使变量存活时间尽可能短 14.1.1 简单if-then语句 2013-01-06 11:13:59 把正常情况放在if后面而不是else后面。 14.2.2 用case语句该注意的几点 2013-01-06 11:15:13 把各种情况按字母或数字顺序组织。如果各种情况是同等重要的,按A-B-C顺序安排,以提高可读性。每个事件都可很容易从整体中挑出来。 把正常情况的事件放在最开始。如果是一个正常情况及几个异常情况,把正常情况放在最先,并用注释标明哪些是正常情况哪些是异常情况。 按出现频率组织情况。 15.2.5 检查循环边界 2013-01-06 11:17:15 要特别小心一个循环中许多 break 语句分散出现的情形。一个循环中包含了许多 break,则表明对循环的结构或者对周围代码的作用还考虑得不清楚。 2013-01-06 11:17:25 把 continue 放在循环的头前检查。c 2013-01-06 11:17:31 检查循环边界 15.3 编写循环的简单方法——从里到外 2013-01-06 11:17:47 编写循环的简单方法——从里到外 16.2 Return语句 2013-01-06 11:18:56 减少每个程序中的 return 语句。 16.3.2 怎样用递归 2013-01-06 11:19:21 要保证递归能终止。 2013-01-06 11:19:28 设置安全计数器防止无限递归 26.3 修改错误 2013-01-06 23:05:14 在改正问题前真正了解其实质 2013-01-06 23:05:32 理解整个程序,而不只是了解某个问题 2013-01-06 23:05:54 确诊错误 2013-01-06 23:06:26 保存初始源代码 26.4 调试心理因素 2013-01-06 23:07:25 寻找相似错误
回应 2013-01-08 21:22:05 -
tyger (耐心、专注)
chp.1 Software Construction ——这一章作者解决了software construction所包含的内容,以及为什么要包含这些内容。 #Problem definition #Requirements development -Construction planning #Software architecture/High level design -Detailed design -Coding and debugging -Unit testing -Integration testing -Integration #System testing #Corrective maintenance #注释的为相关话题,本书中不作为重点讨论;其它内容...2011-05-09 23:19:34
chp.1 Software Construction ——这一章作者解决了software construction所包含的内容,以及为什么要包含这些内容。
#Problem definition #Requirements development -Construction planning #Software architecture/High level design -Detailed design -Coding and debugging -Unit testing -Integration testing -Integration #System testing #Corrective maintenance 引自第3页 #注释的为相关话题,本书中不作为重点讨论;其它内容被包括进construction。
A classic study by Sackman, Erikson, and Grant showed that the productivity of individual programmers varied by a factor of 10 to 20 during construction (1968). 引自第3页 ——这个应该不止,可能需要更详细的说明:比如同样的教育水平、同等的工作经历情况下的比较等。
no matter how rushed or poorly planned a project is, you can’t drop construction. 引自第3页 ——这话实在,1、有些流程确实没必要;2、技术人员讨厌繁琐、无用的流程。所以工业上有时候就都简化了,但作者说的这些差不多是构建一个生产软件流程的最小集合了。
回应 2011-05-09 23:19:34
-
一个循环只做一件事 仅靠循环可同时做两件事的这一事实,是无法充分证明这两件事是应该放在一起做的。循环应该和子程序一样,每个循环只做一件事 支 并且把它做好。如果用两个循环会导致效率低下,而使用一个循环很合适,那么就把代码写成两个循环,并注明可以把它们合并起来以提高效率,然后等测量数 据显示程序的这一部分性能低下的时候再去合并它们。
2022-08-08 12:47:26
-
隔栏的使用使断言和错误处理有了清晰的区分. 隔栏外部的程序应使用错误处理技术, 在那里对数据做的任何假定都是不安全的. 而隔栏内部的程序里就应使用断言技术, 因为传进来的数据应该已在隔栏时被清理过了. 如果隔栏内部的某个子程序检测到了错误的数据,那么这应该是程序里的错误而不是数据里的错误. 隔栏的使用还展示了"在架构层次上规定应该如何处理错误"的价值. 规定隔栏内外的代码是一个架构层次上的决策.
2022-07-26 12:50:51
论坛 · · · · · ·
书很好,书名翻译的容易误导人。 | 来自kylin | 5 回应 | 2022-04-14 00:44:38 |
为什么神书现在一直不卖了? | 来自舍命为江山 | 2020-11-23 00:35:56 | |
反复必看书籍 | 来自Lucius | 2018-11-13 23:01:25 | |
这本书过时吗? | 来自百香果是什么果 | 1 回应 | 2018-06-16 04:49:00 |
中国IT行业“好工程师”应该是什么样的?成为优秀... | 来自叶卡 | 2014-09-29 13:39:43 |
> 浏览更多话题
这本书的其他版本 · · · · · · ( 全部11 )
-
Microsoft Press (2004)9.1分 277人读过
-
电子工业出版社 (2008)9.3分 351人读过
-
电子工业出版社 (2007)8.8分 54人读过
-
Microsoft Press (1993)8.7分 19人读过
在哪儿借这本书 · · · · · ·
以下书单推荐 · · · · · · ( 全部 )
- 各学科领域入门书籍 (征羽)
- 豆瓣评分>9的书(100人以上) (阿獠)
- 豆瓣高分书2700本:千人打分不低于8分 (偶就是那个鬼)
- 豆瓣读书评分9分以上榜单 (无人的冬夜)
- 程序员最应该读的图书(中译版) (hongqn)
谁读这本书?
二手市场
订阅关于代码大全(第2版)的评论:
feed: rss 2.0
7 有用 阅微草堂 2015-12-17 08:31:54
前两百页是工程学的基础知识、excel其实就是个简便的数据库兼编程工具,在当前计算机运算能力过剩的情况下,这个软件用处非常大,可以简化大多数办公室的程序化劳动,提升你临时解决批量问题的能力。你用excel能随意搭建逻辑链,把两个不同领域的相关问题结合到一起处理的时候-
1 有用 neo_hunan 2020-03-21 10:03:42
十几年前读过,经常拿起来在查阅一些指导思想,到今天依旧具有普世价值。
0 有用 贺嘉老师 2010-01-28 23:54:15
概要读的一遍
2 有用 ◇ 2013-10-20 17:26:45
比较让人难以相信的是这么厚的一本书居然真的如作者在序言中所说的几乎都是干货 13.10.20:当然没读完 15.05.24:现在读来感觉这确实是入门书,很多东西已经内化成自己的实践了,也发现了一些啰嗦和不清的内容。不过大全还是全,更多的还是不熟悉或者没有实践的内容
1 有用 Whyme Lyu 2010-02-01 14:04:48
缺乏经验, 味同嚼蜡.
0 有用 SunD0wn别丧啊 2022-08-12 09:45:14
所有需要写代码的人都建议读一下。
0 有用 lightsaber 2022-08-09 18:49:40
要多写代码才能懂怎么写好代码,工程代码不可避免的会变味,写代码不是守规矩。让人更容易阅读,更容易修改,然后比较好的实现了工程要求,这就是好带吗。
0 有用 杨清嘉 2022-08-08 11:52:55
吹这本书的人代码量可能不超过一万行,为什么我敢说这种话呢?因为我知根知底的一个傻逼吹来着,瞅丫说那话我就知道丫都没翻开过这本板砖。
0 有用 ipoly 2022-07-28 21:57:36
编程问答社区StackOverflow上最受欢迎的问题之一是每个程序员都应该读的编程图书,Internet Security博客总结了其中十本最有影响力的编程图书,包括: 《代码大全》第二版,《程序员修炼之道》,《计算机程序的构造和解释》第二版,《C程序设计语言》,《算法导论》,《重构:改进现有代码设计》,《设计模式》,《人月神话:软件项目管理之道》,《计算机程序设计艺术》第一卷第三版,《编译器:... 编程问答社区StackOverflow上最受欢迎的问题之一是每个程序员都应该读的编程图书,Internet Security博客总结了其中十本最有影响力的编程图书,包括: 《代码大全》第二版,《程序员修炼之道》,《计算机程序的构造和解释》第二版,《C程序设计语言》,《算法导论》,《重构:改进现有代码设计》,《设计模式》,《人月神话:软件项目管理之道》,《计算机程序设计艺术》第一卷第三版,《编译器:原理、技术和工具》。 (展开)
0 有用 allan 2022-07-24 22:58:44
历时半年,终于翻完了一遍