首页 > 科技 > 计算机 > 计算机科学

代码大全（第2版）

作译者：金戈,汤凌,陈硕张菲

出版时间：2011-10 千字数：0 版次：01-13 页数：964

开本：16(185*230) 装帧： I S B N ：9787121022982

换版：

纸质书定价：￥128.0

库存:有

分享到：

共有图书评论0条【查看评论摘要】

看了又看

{{data.bookName}}

￥{{data.price}}

内容简介

前言

上架建议

作者简介

编辑推荐

音视频专区

第1章  欢迎进入软件构建的世界	3
1.1  什么是软件构建？	3
1.2  软件构建为何如此重要？	6
1.3  如何阅读本书	8
关键点	8
第2章  用隐喻来更充分地理解软件开发	9
2.1  隐喻的重要性	9
2.2  如何使用软件隐喻	11
2.3  常见的软件隐喻	13
软件中的书法：写作代码	13
软件的耕作法：培植系统	14
软件的牡蛎养殖观点：系统生长	15
软件构建：建造软件	16
应用软件技术：智慧工具箱	20
组合各个隐喻	20
更多资源	20
关键点	21
第3章  三思而后行：前期准备	23
3.1  前期准备的重要性	24
前期准备适用于现代软件项目吗？	25
准备不周全的诱因	25
关于开始构建之前要做前期准备的绝对有力且简明的论据	27
3.2  辨明你所从事的软件的类型	31
迭代开发法对前期准备的影响	33
在序列式开发法和迭代式开发法之间做出选择	35
3.3  问题定义的先决条件	36
3.4  需求的先决条件	38
为什么要有正式的需求？	38
稳定需求的神话	39
在构建期间处理需求变更	40
3.5  架构的先决条件	43
架构的典型组成部分	45
3.6  花费在前期准备上的时间长度	55
更多资源	56
关键点	59
第4章  关键的“构建”决策	61
4.1  选择编程语言	61
语言描述	63
4.2  编程约定	66
4.3  你在技术浪潮中的位置	66
 “深入一种语言去编程”的例子	68
4.4  选择主要的构建实践方法	69
关键点	70
第5章  软件构建中的设计	73
5.1  设计中的挑战	74
设计是一个险恶的问题	74
设计是个了无章法的过程（即使它能得出清爽的成果）	75
设计就是确定取舍和调整顺序的过程	76
设计受到诸多限制	76
设计是不确定的	76
设计是一个启发式过程	76
设计是自然而然形成的	76
5.2  关键的设计概念	77
软件的首要技术任务：管理复杂度	77
理想的设计特征	80
设计的层次	82
5.3  设计构造块：启发式方法	87
寻找现实世界中的对象	87
形成一致的抽象	89
封装实现细节	90
当继承能简化设计时就继承	91
隐藏秘密（信息隐藏）	92
找出容易改变的区域	97
保持松散耦合	100
查阅常用的设计模式	103
其他的启发式方法	105
关于设计启发的总结*****	108
使用启发式方法的原则	109
5.4  设计实践	110
迭代	110
分而治之	111
自上而下和自下而上的设计方法	111
建立试验性原型	114
合作设计	115
要做多少设计才够？	115
记录你的设计成果	117
5.5  对流行的设计方法的评论	118
更多资源	119
软件设计，一般性问题	119
软件设计理论	120
设计模式	120
广义的设计	121
标准	122
关键点	122
第6章  可以工作的类	125
6.1  类的基础：抽象数据类型	126
需要用到ADT的例子	126
使用ADT的益处	127
更多的ADT示例	129
在非面向对象环境中用ADT处理多份数据实例	131
ADT和类	133
6.2  良好的类接口	133
好的抽象	133
良好的封装	139
6.3  有关设计和实现的问题	143
包含（“有一个……”的关系）	143
继承（“是一个……”关系）	144
成员函数和数据成员	150
构造函数	151
6.4  创建类的原因	152
应该避免的类	155
总结：创建类的理由	155
与具体编程语言相关的问题	156
6.6  超越类：包	156
更多资源	159
关键点	160
第7章  高质量的子程序	161
7.1  创建子程序的正当理由	164
似乎过于简单而没必要写成子程序的操作	166
总结：创建子程序的理由	167
7.2  在子程序层上设计	168
7.3  好的子程序名字	171
7.4  子程序可以写多长	173
7.5  如何使用子程序参数	174
7.6  使用函数时要特别考虑的问题	181
什么时候使用函数，什么时候使用过程	181
设置函数的返回值	182
7.7  宏子程序和内联子程序	182
宏子程序在使用上的限制	184
内联子程序	184
关键点	186
第8章  防范式编程	187
8.1  保护程序免遭无效输入数据的破坏	188
8.2  断言	189
建立自己的断言机制	191
使用断言的指导建议	191
8.3  错误处理技术	194
健壮性与正确性	197
高层次设计对错误处理方式的影响	197
8.4  异常	198
8.5  隔离程序以免遭由错误造成的损害	203
隔离区与断言的关系	205
8.6  辅助调试代码	205
不要自动地把产品版本的限制强加于开发版本之上	205
尽早引入辅助调试的手段	206
采用冒进式编程	206
计划移除调试辅助代码	206
8.7  确定在产品代码中该保留多少防范式代码	209
8.8  防范式编程时保持防范	210
其他资源	212
关键点	213
第9章  伪代码编程过程	215
9.1  创建类和子程序的步骤概述	216
创建一个类的步骤	216
创建子程序的步骤	217
9.2  伪代码	218
9.3  通过伪代码编程过程创建子程序	220
设计子程序	225
编写子程序	225
检查代码	230
收尾工作	232
根据需要重复上述步骤	232
9.4  伪代码编程过程之外的其他方案	232
关键点	234
第10章  使用变量的一般事项	237
10.1  数据认知	238
数据认知测试	238
有关数据类型的其他资源	239
10.2  轻松掌握变量定义	239
隐式声明	239
10.3  变量初始化原则	240
10.4  作用域	244
使变量引用局部化	245
尽可能缩短变量的“存活”时间	246
减小作用域的一般原则	249
有关缩小变量作用域的说明	250
10.5  持续性	251
10.6  绑定时间	252
10.7  数据类型和控制结构之间的关系	254
10.8  为变量指定单一用途	255
关键点	258
第11章  变量名的力量	259
11.1  选择好变量名的注意事项	259
最重要的命名注意事项	260
以问题为导向	261
最适当的名字长度	262
变量名字的效果范围	262
变量名字中的计算值限定词	263
变量名字中的常用反义词	264
11.2  为特定类型的数据命名	264
为循环索引命名	265
为状态变量命名	266
为临时变量命名	267
为布尔变量命名	268
为枚举类型命名	269
为常量命名	270
11.3  命名规则的力量	270
为什么要有规则？	270
何时采用命名规则	271
正式程度	271
11.4  非正式命名规则	272
语言无关规则的指导原则	272
语言相关规则的指导原则	275
混合语言编程的注意事项	276
命名规则示例	276
11.5  标准前缀	279
用户自定义类型缩写	279
语义前缀	280
标准前缀的优点	281
11.6  创建具备可读性的短名称	282
一般的缩写指导原则	282
语音缩写	282
有关缩写的评论	282
11.7  应该避免的名称	285
关键点	289
第12章  基本数据类型	291
12.1  使用数的普遍规则	292
12.2  整数	293
12.3  浮点数	295
12.4  字符和字符串	297
C中的字符串	299
12.5  布尔变量	301
12.6  枚举类型	303
如果你的语言里没有枚举类型	307
12.7  命名常量	307
12.8  数组	310
12.9  创建你自己的类型（类型别名）	311
为什么创建自己的类型的示例是用Pascal和Ada写的？	314
创建自定义数据类型的指导原则	315
关键点	318
第13章  不常见的数据类型	319
13.1  结构	319
13.2  指针	323
用来理解指针的例子	323
使用指针的一般技巧	325
C++指针	332
C指针	334
13.3  全局数据	335
与全局数据有关的常见问题	335
使用全局数据的理由	338
只有万不得已时才使用全局数据	339
用访问子程序来取代全局数据	339
如何降低使用全局数据的风险	342
其他资源	343
关键点	344
第14章  组织直线型代码	347
14.1  必须有明确顺序的语句	347
14.2  顺序无关的语句	351
使代码易于自上而下的阅读	351
把相关的语句组织在一起	352
关键点	353
第15章  使用条件语句	355
15.1  if语句	355
简单if-then语句	355
if-then-else语句串	358
15.2  case语句	361
为case选择最有效的排序	361
使用case语句的提示	361
关键点	366
第16章  控制循环	367
16.1  选择循环的种类	367
什么时候使用while循环	368
什么时候用带退出的循环	369
何时使用for循环	372
何时使用foreach循环	372
16.2  循环控制	373
进入循环	373
处理好循环体	375
退出循环	377
检查端点	381
使用循环变量	382
循环应该有多长？	385
16.3  轻松创建循环——由内而外	385
16.4  循环和数组的关系	387
关键点	389
第17章  不常见的控制结构	391
17.1  子程序中的多个返回	392
17.2  递归	393
递归的例子	394
使用递归的技巧	396
17.3  goto	398
反对goto的论点	398
支持goto的观点	399
关于goto的虚假辩论	400
错误处理和goto	401
goto和在else子句中的共享代码	406
goto使用原则总结	407
17.4  对不常见控制结构的看法	408
其他资源	408
关键点	410
第18章  表驱动方法	411
18.1  表驱动方法使用总则	411
使用表驱动方法的两个问题	412
18.2  直接访问表	413
示例：一个月中的天数（Days-in-Month）	413
示例：保险费率	415
例子：灵活的消息格式（Flexible-Message-Format）	416
构造查询键值	423
18.3  索引表访问（Indexed Access Tables）	425
18.4  阶梯访问表	426
18.5  表查询的其他示例	429
关键点	430
第19章  一般控制问题	431
19.1  布尔表达式	432
用true和false做布尔判断	432
简化复杂的表达式	434
编写肯定形式的布尔表达式	436
用括号使布尔表达式更清晰	438
理解布尔表达式是如何求值的	439
Writing Numeric Expressions in Number-Line Order	441
按照数轴的顺序编写数值表达式	441
Guidelines for Comparisons to 0	442
与0比较的指导原则	442
Common Problems with Boolean Expressions	443
布尔表达式的常见问题	443
19.2  Compound Statements (Blocks)	444
19.2  复合语句（块）	444
19.3  Null Statements	445
19.3  空语句	445
19.4  Taming Dangerously Deep Nesting	446
19.4  驯服危险的深层嵌套	446
Summary of Techniques for Reducing Deep Nesting	454
对减少嵌套层次的技术的总结	454
19.5  A Programming Foundation: Structured Programming	455
19.5  编程基础：结构化编程	455
The Three Components of Structured Programming	455
结构化编程的三个组成部分	455
19.6  Control Structures and Complexity	457
19.6  控制结构与复杂度	457
How Important Is Complexity?	458
复杂度的重要性	458
General Guidelines for Reducing Complexity	458
降低复杂度的一般原则	458
Other Kinds of Complexity	460
其它类型的复杂度	460
CHECKLIST: Control-Structure Issues	460
检查表：控制结构相关事宜	460
Key Points	461
关键点	461

Preface
    前  言
    普通的软件工程实践与最优秀的软件实践差距巨大——多半比其他工程学科中的这种差距都要大。因此传播优秀实践经验的工具是十分重要的。
    ——Fred Brooks
    我写这本书的首要目的，就是希望缩小本行业中一般商业实践与大师级人物及专家们之间的知识差距。许多强大的编程技术在被编程领域的大众接触之前，都已在学术论文和期刊里尘封了多年。
    虽然近年来前卫的软件开发实践迅速发展，但普通的实践手段并没有太大变化。很多程序的开发仍然是漏洞百出、迟于交付并且超出预算，还有很多根本就无法满足用户的需求。软件业界以及学术界的研究人员已经发现了不少行之有效的实践经验，足以解决自20世纪70年代以来编程领域中日益蔓延的大多数问题。可是这些实践经验很少在高度专业化的技术期刊之外对外发表，所以时至今日大多数编程的机构和组织还没能用上这些技术。有研究表明，一项研发成果从其诞生之日起，到进入商业实践阶段，通常要经历5到15年的时间甚至更长（Raghavan and Chand 1989；Rogers 1995；Parnas 1999）。这本手册就是想缩短这一漫长的过程，让那些关键性的研发成果现在就能为更多编程人员所用。
    Who Should Read This Book
    谁应当阅读本书
    本书中所汇集的研究成果和编程经验，将帮助你创建更高质量的软件，使你能更快速地进行开发，遇到的问题更少。本书将帮你弄明白过去为什么会遇到那些问题，并告诉你如何在将来避免它们。这里所描述的编程实践将帮助你把控更大型的项目，还能在项目的需求发生变动时帮助你成功地维护并修改已经开发出来的软件。
    Experienced Programmers
    经验丰富的程序员
    对于经验丰富的程序员而言，本书正是他们想要的一本翔实、易用的软件开发指南。本书关注的是“构建（construction）”，即整个软件生命周期中最为人熟知的部分；本书把强大的软件开发技术写得让自学的程序员和参加过正规训练的程序员都能读懂。
    Technical Leads
    技术领导
    许多技术领导（或者说是技术带头人）都曾在他们的团队中使用《代码大全》（第一版）培训经验不足的程序员。当然，本书也可以用来填补你自己的知识缺陷。如果你是一位经验丰富的程序员，你不一定会同意我给出的所有结论（如果不是这样，我倒会觉得奇怪）。但如果你阅读本书并思索其中的每一个问题之后，那么几乎不会有人再能提出什么你未曾思考过的软件构建方面的问题了。
    Self-Taught Programmers
    自学的程序员
    如果你没有受过太多的正规训练，本书正是你的良伴。每年约有50000个新手进入这一专业领域（BLS 2004, Hecker 2004），但每年却只有35000个人获得与软件相关的学位（NCES 2002）。从这些数据中我们可以很快得出一个结论——很多程序员并没有接受过软件开发方面的正规教育。在许多新兴的专业人员社群中都可以看到自学的编程人员——工程师、会计师、科学家、教师以及小公司的老板们；编程序是他们工作的一部分，但他们并不一定把自己看作是程序员。无论你在编程方面受过何种程度的教育，本手册都会让你能对各种行之有效的编程实践有深入的了解。
    Students
    学生
    与有经验但缺乏正规培训的程序员对应的，是那些刚刚毕业的大学生。新近毕业的学生大多拥有丰富的理论知识，但却缺乏创建产品级的程序（production programs）的实践技术。关于编写优秀代码的实践知识，就像部落里祭祀仪式上的舞蹈一样，只能慢慢地从软件架构师、项目负责人、分析师以及更有经验的程序员那里传承下来。更多的时候，这些知识就是程序员个人反复的尝试和犯错后的结晶。本书则是这些缓慢、传统的智慧传承方式的一种替代方案，它汇集了以往只能从他人经验中猎取和收集的大量实用的经验技巧和有效的开发策略。对于那些正在从学术环境转向专业环境的学生来说，这是一本必备的读物。
    Where Else Can You Find This Information
    还能从何处找到这些信息
    本书综合整理了来自四面八方的多种软件构建技术。这些技术是软件构建领域长年累月积聚下来的智慧财富，它们不仅分散，而且其中大部分素材常年散落于纸面之外（Hildebrand 1989，McConnell 1997a）。其实，内行的程序员们所用的那些强大有效的编程技术并不神秘。但是这些内行人士面对手头日复一日紧张冲刺的项目，几乎没有谁花些时间和大家分享他们所学到的知识和技能。因此，程序员们可能很难找到很好的关于编程的信息来源。
    而本书所描述的技术则填补了入门图书和高级编程图书之间的空白。当你读过了《Java编程入门》、《高级Java编程》和《高高级Java编程》之后，如果你还想学更多的编程知识，那还能读点什么呢？你可以阅读Intel或Motorola的硬件参考手册，阅读Microsoft Windows或Linux操作系统的函数手册，甚至是去阅读讲另外一门编程语言的书籍——你确实无法在一个缺乏这种详细参考资料的环境中使用语言或者程序。但本书是为数不多的探究编程本质的书籍之一。无论你在何种环境下、用何种语言编写程序，书中某些最有益处的编程技术都能派上用场。其他的书一般都忽略了这些实践知识，而这也正是本书专注于这些知识的原因。
    本书中的信息是从许多来源中提炼出来的，如下图所示。想完全获得在本书中看到的这些信息的另外途径只有一条，那就是通读堆积如山的书籍和成百上千本技术期刊，还得再加上大量的实际经验。即便你把这些事情都做到了，本书仍然会对你很有益处，因为它把所有这些资料都集于一处，便于查阅。
      
    Key Benefits of This Handbook
    阅读本书的收益
    无论你是何种背景，本书都能助你在更短的时间内写出更棒的程序，还不会那么头疼。
    全面的软件构建参考  本书讨论了软件构建活动的方方面面，比如说软件的质量，还有编程的思维方式。它还会深入阐述构建活动中的重要细节，如创建一个类的步骤，使用数据和控制结构时的各种事项，还有调试、重构、代码调优的技术与策略等。你无须逐页通读所有主题。本书写得让你很容易就能找到感兴趣的特定话题。
    随时备用的核对表  本书包括了大量的核对表（checklist），你可以用它来评估软件架构、设计方法、类和子程序的质量、变量命名、控制结构、代码格式、测试用例等等。
    与时俱进的信息 本书介绍了一些当今最为入时的技术，其中有许多还未被广泛采用。正因为本书撷取了实践与研究两者的精髓，它所介绍的这些技术将经久不衰，受用多年。
    以更广的视角检视软件开发 本书将给你一个机会，让你凌驾于日复一日、忙于救火的混乱场面之上，看看到底什么是可行的，而什么又是不可行的。实践中的程序员们很少有时间去阅读数以百计的书籍与期刊，而本手册萃取了其中的精华。本书所汇集的理论研究与实践经验将活跃你的思维，激励你对自己项目的思考，使你的行动更有策略，避免反复陷入完全一样的战斗。
    绝不注水 有些软件书籍，其中精髓部分的净重也就1克，却注入了重达10克的水分。本书则会公平地探讨每项技术的优劣。关于你自己项目的特定需求，你了解得要比任何人都清楚。因此本书仅是给你公正客观的信息，让你能够具体情况具体分析，做出正确的决策。
    有关概念适用于大多数常见的语言 本书中介绍的技术能让你可以更好地利用你的编程语言，无论是C++、C#、Java、Visual Basic，还是其他类似语言。
    丰富的代码示例 本书中收集了近500个用于展现优、劣代码之差异的示例。之所以给出这么多示例也是出于个人的偏好。因为从示例中我最能学到东西，我想其他程序员也该可以通过这种方式学得更好吧。
    这些示例是用了多种不同的语言所写成，因为学习并掌握不止一门语言通常是专业程序员职业生涯中的分水岭。一旦一名程序员意识到编程原则是超越特定语言语法的东西时，通往能够实质地改善编程质量并提高工作效率的知识的大门也就向他敞开了。
    为了避免以多种语言写成的例子成为读者的负担，我会尽量避免使用各语言中那些深奥的特性——除非当时就是需要探讨它。为了弄懂一个代码片段要表达的问题，你无须完全理解所有的细枝末节。如果你集中关注示例所展示的问题，那么无论它是用什么语言写成的，你都能读懂。为让你更容易理解这些示例，我还给其中的关键部分加了注解。
    引用其他信息来源  本书汇集了为数众多关于软件构建方面的可用信息，但这并不算完。在本书所有的章节中，“更多资源”一节都会介绍其他一些书籍和文章，你希望进一步深入了解感兴趣的话题时可以阅读它们。
     
配套网站  在本书的配套网站cc2e.com上会提供更新的核对表、参考书目、杂志文章、网页链接等内容。要访问《代码大全》（第二版）中的相关信息，请如本段文字左侧所示，在浏览器中输入“cc2e.com/”，后跟一个四位阿拉伯数字即可。这样的网址参考链接在本书中会有很多。 
    Why This Handbook Was Written
    为什么要写这本手册
    在软件工程界，人们都清楚地认识到，应该把软件开发中行之有效的实践知识归纳、编撰成一本开发手册。计算机科学与技术委员会（Computer Science and Technology Board）的一份报告指出，要想大幅提高软件开发的质量和工作效率，需要把已知的行之有效的软件开发实践知识归纳、统一并广为传播（CSTB 1990, McConnell 1997a）。该委员会还指出，传播这些知识的策略应建立在软件工程手册这个概念的基础之上。
    The Topic of Construction Has Been Neglected
    软件构建的话题常被忽视
    曾几何时，软件开发和编写代码被认为是同一件事情。但随着软件开发周期中的各个活动被人们逐渐认识，该领域中一些最棒的头头脑脑们就开始花更多时间去分析和争论诸如项目管理方法、需求、设计、测试等问题了。在这场学习研究新兴领域的浪潮中，代码构建这个与软件开发骨肉相连的环节反而被忽视了。
    关于软件构建的讨论之所以步履蹒跚，也是因为有人认为，如果将构建活动视作软件开发中的一项特定活动，就暗示着也必须把它视作其中一个特定阶段。然而实际上，软件开发中的各项活动和各个阶段无须以特定的关系一一对应起来；而且无论其他的软件活动是分阶段（phase）进行、还是迭代式（interation）进行，或者以某种其他方式进行，都不妨碍我们探讨“构建活动”。
    Construction Is Important
    构建活动是重要的
    构建活动被学者和作者所忽略的另一个原因是源于一个错误的观念，他们认为与其他软件开发活动相比，构建是一个相对机械化的过程，并没有太多可改进的机会。然而事实并非如此。
    “代码构建”一般占据了小型项目65%的工作量，而在中型项目上也达到了50%。同时，“构建”也要为小型项目中75%的错误负责，在中到大型项目上这一比例为50%到75%。任何一个要为50%到75%的错误负责的活动环节显然都是应该加以改善的。（第27章中对这些统计数据有更多详细的探讨。）
    也有一些评论家指出，虽然构建阶段发生的错误在所有错误中占有很大的比例，但修正这些错误的代价往往比“修正那些由于需求和架构所导致的错误”要低很多，这也就暗示着构建活动因此不那么重要。诚然，修正由构建活动所导致的错误的代价比较低这一说法是正确的，但它也引起了误导——因为如果不修正这些错误，代价反而会高得令人难以置信。研究人员发现，软件中一些代价最为昂贵的错误，其罪魁祸首常常是一些小范围的代码错误，其代价甚至可以飙至上亿美元的程度（Weinberg 1983，SEN 1990）。可以用较低代价修正的错误，并不意味着这些错误的修正不重要。
    人们忽视构建活动的另一种原因则颇具讽刺意味——就因为它是软件开发中唯一一项肯定能完成的活动。对于需求，人们可以自以为是而不去潜心分析；对于架构，人们可以偷工减料而不去精心设计；对于测试，人们可以短斤少两甚至跳过不做，而不去整体计划并付诸实施。但只要写出来的是程序，总归要进行构建活动，这也说明，只要改进软件构建这一环节，就一定对软件开发实践有好处。
    No Comparable Book Is Available
    没有可媲美的同类书籍
    既然看到构建活动有着如此清晰的重要性，我曾相信，当我构思此书时已有人写过关于有效的软件构建实践的书籍了。对这样一本介绍如何有效地进行编程的书籍的需求是显而易见的，但是我却只找到很少几本关于软件构建这一题材的书，而且那些书也仅是涉及到这个话题的一部分罢了。有些书写于15年前，还是和一些深奥的语言——如ALGOL、PL/I、Ratfor以及Smalltalk等——紧密相关的。有些则是出自并不实际编写产品代码的教授之手。教授们写出来的技术内容对于学生们的项目而言还行得通，但他们通常不知道如何在完整规模的开发环境中施展这些技术；还有些书是为了宣传作者最新钟情的某种方法论，却忽略了那些被时间反复证明是行之有效的成熟实践技术的巨大宝库。 
    简而言之，我没有找到哪怕是一本试图归纳总结来自专家经验、业界研究以及学术成果的实践编程技术的书籍。关于这个话题的讨论要能和现今的编程语言、面向对象编程技术以及前沿的开发实践紧密结合。很明显需要有人写出一本这样的书出来，而他必须了解当今的理论发展水平，同时也编写过足够多的能反映实践状况的产品级代码。我把本书构思成关于代码构建活动的完整探讨——一个程序员给其他程序员写的书。
     
Author Note
    作者注
    欢迎您对本书中所探讨的话题进行质询，例如您的勘误报告，或其他相关的内容。请发邮件与我联系，我的邮箱是stevemmc@construx.com，也可以访问我的网站：www.SteveMcConnell.com。
    Bellevue, Washington
    Memorial Day, 2004
    
Microsoft Learning Technical Support    Every effort has been made to ensure the accuracy of this book. Microsoft Press provides corrections for books through the World Wide Web at the following address:    http://www.microsoft.com/learning/support/    To connect directly to the Microsoft Knowledge Base and enter a query regarding a question or issue that you may have, go to:    http://www.microsoft.com/learning/support/search.asp    If you have comments, questions, or ideas regarding this book, please send them to Microsoft Press using either of the following methods:    Postal Mail:    Microsoft Press    Attn: Code Complete 2E Editor    One Microsoft Way    Redmond, WA 98052-6399    E-mail:    mspinput@microsoft.com

查看更多 > 图书评论

暂无评论

发表图书评论

评论标题：
评论内容：
验证码：: 看不清楚
点击刷新
: 您还没有登录，请登录后再评论。
点击“登录”

购买过本书的顾客还买过

{{data.bookName}}

￥{{data.price}}