Name: 代码大全（第2版）
ISBN: 9787121022982

作者: [美] 史蒂夫·迈克康奈尔
出版社: 电子工业出版社
出品方: 博文视点
原作名: Code Complete
译者: 金戈 / 汤凌 / 陈硕 / 张菲译 / 裘宗燕审校
出版年: 2006-3
页数: 944
定价: 128.00元
装帧: 平装
丛书: 传世经典书丛
ISBN: 9787121022982

豆瓣评分

9.3

3508人评价

5星

71.1%
4星

23.0%
3星

5.1%
2星

0.5%
1星

0.3%

评价:

内容简介 · · · · · ·

第2版的《代码大全》是著名IT畅销书作者史蒂夫·迈克康奈尔11年前的经典著作的全新演绎：第2版不是第一版的简单修订增补，而是完全进行了重写；增加了很多与时俱进的内容。这也是一本完整的软件构建手册，涵盖了软件构建过程中的所有细节。它从软件质量和编程思想等方面论述了软件构建的各个问题，并详细论述了紧跟潮流的新技术、高屋建瓴的观点、通用的概念，还含有丰富而典型的程序示例。这本书中所论述的技术不仅填补了初级与高级编程技术之间的空白，而且也为程序员们提供了一个有关编程技巧的信息来源。这本书对经验丰富的程序员、技术带头人、自学的程序员及几乎不懂太多编程技巧的学生们都是大有裨益的。可以说，无论是什么背景的读者，阅读这本书都有助于在更短的时间内、更容易地写出更好的程序。

作者简介 · · · · · ·

史蒂夫·迈克康奈尔（Steve McConnell）被公认为软件开发社区中的首要作者和发言人之一。他是Construx Software公司的首席软件工程师。他所编著的图书包括曾被《软件开发》杂志授予优异产品震撼大奖的《代码大全》和《快速软件开发》，以及《软件项目生存指南》和《专业软件开发》等等。

目录 · · · · · ·

第 1 章欢迎进入软件构建的世界　　3
第 2 章用隐喻来更充分地理解软件开发　　9
第 3 章三思而后行：前期准备　　23
第 4 章关键的“构建”决策　　61
第 5 章软件构建中的设计　　73
第 6 章可以工作的类　　125
· · · · · · (更多)

"代码大全（第2版）"试读 · · · · · ·

CodeGear首席技术官（CTO）李维——代码大全是我早在好几年前便已经阅读过的好书。这几年来我不知买过多少书籍，也清理过许多因为书房再也放不下的书籍，但是代码大全这本书始终占据着我书架上重要的位置而不曾移开过，因为好书是经得起时光考验的。微软亚洲研究院研究员潘爱民——在众多的编程类书籍中，如果只让我挑一本书来阅读，那我一定选择《代码大全》，因为它是最不可或缺的..

第1部分基础信息

· · · · · · (查看全部试读)

豆瓣成员常用的标签(共771个) · · · · · ·

编程代码大全软件开发计算机软件工程程序设计 programming 代码

丛书信息

　　传世经典书丛 (共14册), 这套丛书还有《提高C++性能的编程技术》,《Exceptional C++（中文版）》,《Effective C++》,《编码》,《程序员修炼之道》等。

喜欢读"代码大全（第2版）"的人也喜欢的电子书 · · · · · ·

支持 Web、iPhone、iPad、Android 阅读器

: CoffeeScript小书

1.99元

: 我编程我快乐

18.00元

: MacTalk·人生元编程

2.99元

: 编程大师访谈录

24.99元

: Python源码剖析

38.39元

喜欢读"代码大全（第2版）"的人也喜欢 · · · · · ·

: 设计模式

: 程序员修炼之道

: 重构

: UNIX编程艺术

: 深入理解计算机系统

: 算法导论（原书第2版）

: 人月神话

: 计算机程序的构造和解释

: 敏捷软件开发

: 编程珠玑

我来说两句

短评 · · · · · · ( 全部 656 条 )

代码大全（第2版）的话题 · · · · · · ( 全部条 )

什么是话题

无论是一部作品、一个人，还是一件事，都往往可以衍生出许多不同的话题。将这些话题细分出来，分别进行讨论，会有更多收获。

我要写书评

代码大全（第2版）的书评 · · · · · · ( 全部 115 条 )

软件构建的核心就是管理复杂度

啊，也不知道多少天了，终于啃完了大部头Code Complete。经典就是经典，确实受益匪浅。总结一下，其实让我记忆深刻的主要是两点：首先，软件构建的核心就是管理复杂度。虽然书中有不少的篇幅来讨论变量、语句等等这些编程的基本要素，还包括代码改善和调整的策略和方法，... (展开)

125

3 36回应

庄表伟 2006-05-05 10:07:25

《代码大全》——软件开发的世界地图

　　我有很浓厚的“地图情结”，以前我写过一篇《我的信仰地图》，最近又做了一次关于Ajax的演讲，名字叫做《Ajax技术地图》。我一直以来的观点是，世界是一个整体，在这个巨大的世界之中，任何事物、任何知识，任何观点，都有其合理、自然的位置。理解这个世界的过程，就是逐... (展开)

14 16回应

云风 2006-06-09 19:13:36

我的一些读书笔记

因为最近工作很忙, 所以这本书的厚度让我迟迟没有读完. 间隙的写了点读书笔记, 可以和大家分享: http://blog.codingnow.com/cloud/CodeComplete (展开)

3 10回应

rocedu 2006-09-19 09:57:59

代码大全中英文要点

《代码大全》是一本不多见的值得多次阅读的好书，在《代码大全》一书中，每一章后面都有这一章的要点,略读这些要点中我们就可以了解到我们已经掌握了哪些知识,哪些知识还没有掌握，阅读，重读时就有重点了。下面列出这些要点，供没有购买这本书的同学（同仁）参考，或可用作决... (展开)

5 13回应

想飞的猫 2009-11-11 15:39:48

堪称经典的力作

想要学习软件开发的都应该去读这本书。书里面有很多一般很难接触到的最佳实践的东西。很多时候，这些也就是新手和高手之间的区别。当你知道了很多这些东西之后，也就很难有人再去叫你菜鸟。我认为本书最值得去读的是中间那几章很详细的细节方面的描述，如变量命名之类。我也... (展开)

2 14回应

琳琳的小狗 2009-07-28 10:07:04

金砖：）

超厚的一本书，堪称砖头，在我的记忆里，估计只有牛津英汉辞典能赶上他把，呵呵。也难怪，要容纳这么多的软件开发思想、经验总结，就非得那么多篇幅才可能，忍了。李维说此书始终在他的书架上，此话不假，至少，你细心看完这本书，没有几个月下来那是绝对不可能，而且，就算你... (展开)

4回应

sheep 2009-08-06 15:08:06

只是从个人性格来看

这篇书评可能有关键情节透露

这是一部讲软件构建的书，所以它会偏向于软件工程，而又涵盖编程技术。如果只是专注于技术细节，读完这本书中的几章可能会让你有意犹未尽的感觉，但如果你要走得更远一些的话，应该更进一步，从整体来看软件是如何构建的，这也是书名“code complete”的寓意所在。但一下就谈... (展开)

5回应

草根程序员 2010-03-04 14:31:04

软件构建的集大成者

初见《代码大全》，还是该书的第一版，只从书名上看，还以为都是一些代码的示例。觉得还有很多的书需要读，这种实用主义的技巧书，可以先放一放，于是与之失之交臂。及至后来，才发现原来被中文书名给骗了。只要将目录浏览一过，就会发现，这本书基本覆盖了软件构建的全过程... (展开)

2 5回应

久遠寺秋水 2009-07-31 12:48:09

人类统治代码，而不是代码统治人类

　　《Write Great Code》在第一卷的1.4里就说到，卓越代码需要“易读并且容易维护”、“风格统一”、“涉及清晰，遵循成熟的软件工程惯例”，而《Code Complete》教给我们的，正是开启这扇卓越代码之门的第一把钥匙。　　我是在初二接触到《Code Complete》一书的，而现在这... (展开)

4回应

zaohe 2010-01-20 17:39:18

有真正项目经验后收获更多

之前非常忽视代码层次的书，看的都是一些设计、计算机原理方面的书籍。看完这本书后，自己的代码质量有了本质的提升，同时也对另外的一些描述代码的经典书籍发生了兴趣。发现自己原来连程序员一直都没入门。啥也不说了，努力学习吧，书看了肯定有收获的。 (展开)

1回应

> 更多书评115篇

读书笔记 · · · · · · (共399篇)

我来写笔记

按有用程度
按页码先后
最新笔记

展开收起
all

Phil菠菜

开着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 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
展开收起
全书文摘

Suave (trust instinct, be visionary)

设计是一个启发式过程隐喻是启示而不是算法典型情况下需求会有多少改动？IBM和其他公司的研究发现，平均水平的项目在开发过程中，需求会有25%的变化（Boehm 1981，Jones 1994，Jones 2000）。在典型的项目中，需求变更导致的返工占到返工总量的75%到85%（Leffingwell 1997，Wiegers 2003）。注意项目的商业案例：有些需求作为功能特色来看是不错的想法，但是当你评估“增加的商业价值”时就会觉得它是个糟透了的主意。...
2012-02-14 14:09 5人喜欢

设计是一个启发式过程
隐喻是启示而不是算法
典型情况下需求会有多少改动？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
展开收起
第430页

coco+ (程序猿出没)

1.表驱动法：从表里查找信息而不是使用逻辑语句(if 和 else），用直接访问代替复杂的逻辑控制结构，例如字符分类，月中的天数和保险费。 2.如果有多种不同的消息，而且这些消息可能改变，可能增加，最好使用表驱动法，因为你不得不为每一种消息建立函数或类，如果里面的数据类型改变，你甚至要改变程序逻辑。而使用表驱动，只需要编写少量的代码就可以完成任务。 3.构造查询键值。有时候并不能直接拿数据作为键值直接访问表...
2014-10-28 22:29 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
展开收起
第74页

Suave (trust instinct, be visionary)

“险恶的(wicked)”问题就是那种只有通过解决或部分解决才能被明确的问题(1973)。这个看似矛盾的定义其实是在暗示说，你必须首先把这个问题“解决”一遍以便能够明确地定义它，然后再次解决该问题，从而形成一个可执行的方案。这一过程已经如影随形地在软件开发中存在数十年了(Peters and Tripp 1976) 的确，如何全面的分析所面对的问题是最棘手的事情。面对所要构建的系统，我更推荐先仔细查找、分析你所能找到的所有类型系统..
2012-05-07 13:37 2人喜欢

“险恶的(wicked)”问题就是那种只有通过解决或部分解决才能被明确的问题(1973)。这个看似矛盾的定义其实是在暗示说，你必须首先把这个问题“解决”一遍以便能够明确地定义它，然后再次解决该问题，从而形成一个可执行的方案。这一过程已经如影随形地在软件开发中存在数十年了(Peters and Tripp 1976)
的确，如何全面的分析所面对的问题是最棘手的事情。面对所要构建的系统，我更推荐先仔细查找、分析你所能找到的所有类型系统、设计、代码。经验标明，系统中的80%的部分应该能找到参照系，这也是 80/20 原则。在这样的指导建议下，能很大程度上降低设计的难度和风险

推荐

回应 2012-05-07 13:37

展开收起
第1页

[已注销]

云风的笔记：http://blog.codingnow.com/cloud/CodeComplete (5回应)
2011-08-31 20:32

云风的笔记：http://blog.codingnow.com/cloud/CodeComplete

推荐

5回应 2011-08-31 20:32
展开收起
第1页

Breaker Zhao

练习代码 CC2E Ch18TableDriven BuoyInfo: 讲述表驱动方法的章节中 (P411)，读取和输出水中浮标数据的示例程序改进版。分离消息描述和消息数据，详见 BuoyMsg.h 头部注释。
2012-09-02 15:53

练习代码 CC2E
Ch18TableDriven BuoyInfo: 讲述表驱动方法的章节中 (P411)，读取和输出水中浮标数据的示例程序改进版。分离消息描述和消息数据，详见 BuoyMsg.h 头部注释。

推荐

回应 2012-09-02 15:53
展开收起
第1页

叫什么好

代码大全 3.1.2 在进行创建工作之前必须做准备工作的论据 2013-01-06 08:26:42 在一个正常的生态系统中，海鸥以沙丁鱼为食，沙丁鱼吃鲜鱼，鲜鱼吃水虱，其结果会形成一个正常的食物链。在编程工作中，如果软件食物链的每一级都可以吃到健康的食物，其结果是由一群快乐的程序员写出的正确代码。 2013-01-06 08:27:17 如果需求定义遭受了污染，那么这又会影响结构设计，而这将最终影响创建活动。这将导致程序员们脾气暴躁..
2013-01-08 21:22 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
展开收起
第1页

oldfeel (http://git.oschina.net/oldfeel)

因为名字，无数次错过这本书。。。蛋疼！
2013-07-22 00:50

因为名字，无数次错过这本书。。。蛋疼！

推荐

回应 2013-07-22 00:50

展开收起
第510页

半海客

如果你无法重复它，那么就不可能改善它。持续改进，PDCA元知识（P528）开发者测试的局限性： - 干净测试（Clean Tests），5:1！ - 覆盖率估计过于乐观 - 忽视复杂覆盖率明确了数据流的概念，重新认识了数据流测试。本书更像是一位资深顾问的导读。
2018-11-10 10:30

如果你无法重复它，那么就不可能改善它。持续改进，PDCA元知识（P528）
开发者测试的局限性：
- 干净测试（Clean Tests），5:1！
- 覆盖率估计过于乐观
- 忽视复杂覆盖率
明确了数据流的概念，重新认识了数据流测试。
本书更像是一位资深顾问的导读。

推荐

回应 2018-11-10 10:30
展开收起
欢迎进入软件构建的世界

杰良 (继往开来)

构建活动的具体任务（task）验证有关的基础工作已经完成，因此构建活动可以顺利地进行下去。确定如何测试所写的代码。设计并编写类（class）和子程序（routine）。创建并命名变量（variable）和具名常量（named constant）。选择控制结构（control structure），组织语句块。对你的代码进行单元测试和集成测试，并排除其中的错误。评审开发团队其他成员的底层设计和代码，并让他们评审你的工作。润饰代码，仔细进行代码...
2018-11-05 19:21

构建活动的具体任务（task）
验证有关的基础工作已经完成，因此构建活动可以顺利地进行下去。
确定如何测试所写的代码。
设计并编写类（class）和子程序（routine）。
创建并命名变量（variable）和具名常量（named constant）。
选择控制结构（control structure），组织语句块。
对你的代码进行单元测试和集成测试，并排除其中的错误。
评审开发团队其他成员的底层设计和代码，并让他们评审你的工作。
润饰代码，仔细进行代码的格式化和注释。
将单独开发的多个软件组件集成为一体。
调整代码（tuning code），让它更快、更省资源。
一些重要的非构建活动
管理（management）
需求分析
软件架构设计
用户界面设计
系统测试
维护
软件构建为何如此重要
构建活动是软件开发的主要组成部分。
构建活动是软件开发中的核心活动。
把主要精力集中于构建活动，可以大大提高程序员的生产率。
构建活动的产物 —— 源代码 —— 往往是对软件的唯一精确描述。
构建活动是唯一一项确保会完成的工作。

推荐

回应 2018-11-05 19:21
展开收起
欢迎进入软件构建的世界

杰良 (继往开来)

软件开发过程中的主要活动（activity）：定义问题（problem definition）需求分析（requirements development）规划构建（construction planning）软件架构（software architecture）详细设计（detailed design）编码与调试（coding and debugging）电源测试（unit testing）集成测试（integration testing）集成（integration）系统测试（system testing）保障维护（correcting maintenance）
2018-11-05 18:52

软件开发过程中的主要活动（activity）：
定义问题（problem definition）
需求分析（requirements development）
规划构建（construction planning）
软件架构（software architecture）
详细设计（detailed design）
编码与调试（coding and debugging）
电源测试（unit testing）
集成测试（integration testing）
集成（integration）
系统测试（system testing）
保障维护（correcting maintenance）

推荐

回应 2018-11-05 18:52
展开收起
第404页

半海客

重写错误处理的goto，还有几种方法： 1. do { } while (0)； 2. RAII执行代码的方法；另外P393，return错误前置的代码，也算是防御式编程（防卫子句）的一部分，因为return后的代码可以放心地认为是正常情况。防卫子句，又与P356系统处理大量错误的箭头代码相互矛盾。目前，我写的产品代码里，是尽量避免箭头代码的出现。
2018-10-19 08:23

重写错误处理的goto，还有几种方法：
1. do { } while (0)；
2. RAII执行代码的方法；
另外P393，return错误前置的代码，也算是防御式编程（防卫子句）的一部分，因为return后的代码可以放心地认为是正常情况。
防卫子句，又与P356系统处理大量错误的箭头代码相互矛盾。目前，我写的产品代码里，是尽量避免箭头代码的出现。

推荐

回应 2018-10-19 08:23

> 更多读书笔记（共399篇）

论坛 · · · · · ·


反复必看书籍	来自Lucius		2018-11-13
这本书过时吗？	来自杀鸡	1 回应	2018-06-16
这书适合刚工作的吗？	来自胡建炒换	9 回应	2015-12-18
中国IT行业“好工程师”应该是什么样的？成为优秀...	来自叶卡		2014-09-29
这本书翻译如何？	来自Wu Wei		2014-06-11