代码大全（第2版）

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

练习代码 CC2E

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

代码大全 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寻找相似错误

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