《代码大全》是到目前为止，让我感触最深的一部计算机书籍了，对我影响最深，可以说是计算机书籍中的进阶提高班。这是第二遍读《代码大全》了，之前看的有些遗忘，这次决定看书过程中打个标签（Kindle 的多看系统支持 pdf 标记书签，并上传同步到 Evernote 笔记中），而后结合实际的开发经历，写点读书笔记。
《代码大全》–读书笔记
第一章 软件创建的世界
P1：“问题定义、需求分析、实现计划、总体设计、详细设计、创建即实现、系统综合、单元测试、系统测试、校正性维护、功能强化。”
在正式的开发环境中，我们所说的编程包括上述所有，而在非正式或者更简化的环境中，往往只有“创建即实现”的过程。这个过程可以根据实际情况来简化，但是如果做计划的话，编程的时间最多只能占到时间预算的 50%，剩余的时间一定要留给足够的设计和测试（包括自我调适）的时间，设计可以留20%的时间，测试要留30~50%的时间。假如是两周的开发任务，那么必须要在第一周的时间完成设计和编码的工作，在第二周开始则着手测试及调适优化的工作。
第二章 利用隐喻对编程进行更深刻的理解
P9：“建造隐喻暗示了许多诸如计划、准备、执行等工作阶段”。
软件工程和建筑有很多类似的地方。如多大的工程就要费多大的精力去设计，以及多大的人力去建造。但也有更多不同的地方如，软件构建不以人力增加而减小工期，软件构建在后期允许推倒重构设计，但建筑却不行。（不过现在还没想到比“建造”一次更适合软件工程的隐喻）。
第三章、软件创建的先决条件
P30：“如果想开发一个高质量的软件，必须自始至终重视软件质量问题。在开始阶段强调质量往往比在最后强调质量更为有效”、“如果问题定义的不好，那么在编程阶段，所解决的问题可能并不是用户真正要解决的问题。”、“如果需求做的不好，在编程后修改的要比在需求分析时修改的成本要高20~100倍。”
拿到需求就开始写代码的程序员注定是个悲剧。
不搞清楚需求的程序员注定是个悲剧。
编码过程中还没想清楚原理，还没搞清楚问题本质的程序注定是个悲剧。
任何马马虎虎、想蒙混过关的程序员注定是个悲剧。
第四章 建立子程序的步骤
P31:“设计程序、子程序编码、检查代码”。
实际开发中可能从来没有想到过的事情，在这里都有充足的描述。而且每一个过程都极其重要，比如设计程序要求你必须充分理解这段程序的意图，输入，输出，面向对象、过程或模块设计；子程序编码要求代码规范，布局美观已读，逻辑最简化最清晰化；检查代码要求自我阅读排错，减少后期出现bug时调适的时间，我们往往会犯这种2的事情，测试后期出了问题，结果花费了几天的时间才解决，最终才发现可能就是一个逻辑判断出错的原因，导致耗时耗精力，这种消耗毫无意义，不要觉得自己找个bug很厉害，你应该感到耻辱，去反思问什么会出现这么2的事情。良好的设计、编码、检查，会大大减低这类事情的出现。
第五章 高质量子程序特点
P51：“创建子程序的目的：降低复杂性、避免重复代码、限制改动带来的影响、隐含顺序、改进性能、进行集中控制、隐含数据结构、隐含指针操作、隐含全局变量、重用代码、形成公用基础库、改善可读性、分割复杂性”。
“子程序的命名恰当：动词+名词、避免无意义或者模棱两可、描述子程序的过程、长度要合适（9-15个字符）”
P52：“强内聚：功能、逻辑、过程内聚”
P60：“子程序的长度：100~150行是最佳子程序长度，较强的可维护性、较低代码错误概率。”
P61：“防御性编程：多用断言、做好异常处理、做好返回值处理、提早加入DEBUG信息”。
P67：“子程序参数：顺序是输入、修改、输出；最大参数是7个；考虑怎样区分输入、修改、输出，如加宏定义”
第六章 模块化设计
P75：“模块化：内聚性与耦合性，信息隐藏”
P90：“创建模块的原因很多与创建子程序相同。但模块的概念意义比子程序深远得多。它是比子程序更高层次的设计工具”。
子程序、模块、面向对象。本质上都是一样的，是对问题的抽象思考，抽象的水平越好，代码能力越强。
第七章 高级结构设计
P93：“设计的层次：划分子系统，划分模块，划分子程序，子程序内部的设计”
P97：“自底向上的合成、自顶向下的分解”
P98：“面向对象：抽象、封装、模块、继承”
P105：“往返设计即重构设计，在代码的某一阶段，鼓励重构代码”
设计其实是一个抽象的过程，把问题和事情想清楚了，简单化，抽象化是基本的原则，不论是何种设计、何种工具，目的都在于此。代码的重构，要求的是在考虑到后期维护费劲，且本次修改能有效改善后期阅读和维护的效果，完全可以鼓励重构，要记住代码编写出来后剩下的时间都是在阅读代码，宁愿现在写好点也不要以后阅读耗费更多时间和精力。
第八章 生成数据
第九章 数据名称
P121：命名的首要素是自解释，9~15字符。在常用名称中，要注意其反义词，如insert/delete，open/close，start/stop。循环变量可以用i,j,k，注意临时变量也要好好命名。逻辑变量要用肯定的逻辑，如Done、Error、Success，而不要用 NoDone、NoError、NoSuccess等；枚举内部加前缀，表示在同一组，如Type_Red,Type_Blue。类成员用 m_nBookCounts，临时变量用 nBookCounts。最重要的核心思想是代码自解释。如果你后期再读一遍代码时候感到费劲，那么你可以考虑修改你的代码命名了。
第十章 变量
P142:
尽量减少作用域的范围，不要把一个变量到到处放置，最好集中管理，减少人在同一时间内的要记忆的东西。
变量功能单一
尽量避免全局变量使用,如果必须使用则建立明显标示，如 s_BookCounts，用存取子程序来控制成员变量，而不是随意读写。
第十一章 基本数据类型
P154：
避免使用魔术数字，如 60 秒，可以使用宏 ONE_MINITE_PER_SECONDS = 60 来代替。
检查数据溢出，浮点数不能直接 == 判断
字符串应该初始化为 0
小心数组越界
第十二章 复杂数据类型
P179：
用结构体或者类来代替一堆变量。
表驱动法。例如在 HTTP 请求函数里，可以加一个 map,<string, point>让变量对应函数指针，查找时只需要find map的变量名即可。
抽象数据定义。如类对象的操作，把数据和对数据的操作封装一个类。
第十三章 顺序程序语句
P201：
程序能够由上而下的阅读，变量存活尽量短。相关的语句组织在一起。
DealWindows_1();
DealWindows_2();
DealMessage_1();
DealMessage_2();
第十四章 条件语句
P208：
if else，先写正常，再写异常。
case 也是先正常，后异常处理
第十五章 循环语句
控制好 while 循环，最好只保持在一个地方break，不要在很多地方判断 break，如
if( bSucess || bOver || bTimeout) break;
循环的层次不要超过三层，否则就要考虑使用子函数类处理复杂逻辑。
第十七章 常见的控制问题
简化复杂语句，防止深层嵌套，
第十八章 布局与风格
基本原则是清晰易懂，风格统一。
空格来区分变量和字符串，
空行来划分逻辑分区，分段
对齐和缩进是最基本的语段内逻辑显示控制。
注释和上一段落保持一行
第十九章 文档
P313：
综合资料，软件的非正式文档，可以是查阅的参考资料等，放置在一起，供参考用。
详细设计文档，低层的代码设计和实现文档，可以有，也可以在代码中自解释。
有效的注释，是对一段代码的意图做说明。
第二十章 编程工具
选择固定好用的 IDE 作为开发工具，不要让工具成为累赘，而要让工具成为利器。让更多的精力花费在文档、代码、思考上，而不是花费在捉摸 IDE 工具！！！
第二十一章 项目大小如何影响创建
第二十二章 创建管理
强调代码是公用财产，写代码的目的之一是要让别人看的。
程序员怎样花费自己的时间。每天8小时，只要有5个小时全心投入工作就可以了，剩余的3个小时完全可以休息。
能力差别。同样工龄的程序员，最高效和最低效的比是 25：1 。这个数字比较震撼，看似同样经验的程序员，能力有天壤之别。
第二十三章 软件质量
可维护、可理解、灵活性、可移植性、可重用、可读性。
多设计文档的检查、非正式组内检查、设计检查、正式代码检查、人工代码检查、单元测试、功能测试、系统测试。
阅读代码改错的效率要比调适bug的效率高很多
第二十四章 评审
当局者迷，旁观者清，让别人检查你的工作时正确的。
代码阅读要比其他调适方式多发现 20~60%的bug
第二十五章 单元测试
第二十六章 调试
P417：
调试的误区：靠猜发现错误，不花费时间理解问题，不理解代码就盲目的修改，不注意编译器警告
第二十七章 系统集成
递增基层法
第二十八章 代码调整策略
第二十九章 代码调试技术
第三十章 软件优化
第三十一章 个人性格
P501：
优秀的程序员不一定最聪明，但一定是最谦虚，因为谦虚保持了持续的学习性。
写代码之前先做好分析再下手。
读别人的代码，好的代码或者差的代码，对自身都是一种学习。
大师：大师有着专家对语言环境很深的造诣，并意识到编程知识 15%和计算机交流，其余85%是和人打交道。大师的代码是给人看的，不是给计算机看的，很浅显易懂
第三十二章 软件开发的有关问题
P511：
减少复杂，抽象复杂。以人为本，代码是给人看的，不是简单的应付编译器。