初读云风大大的读书笔记，收获蛮多，云风大大的读书笔记只记录了1到442页的。我直接读了400页之后的，也做了后续的读书笔记。《代码大全》第二版确实是一本好书，每个人读了能领悟的东西并不一样，本读书笔记是博主略有领会的东西，分享出来是希望没读此书的人有所收获，要是能引起你对《代码大全》的兴趣，去通读本书的话就更好了。
另附云风大大的1到442页读书笔记链接：http://blog.codingnow.com/cloud/CodeComplete
P439 短路求值，更好的办法是使用嵌套循环，而不是依赖求值的顺序或者短路求值。
P440 数轴排序法
判断顺序i>minValue and i>maxValue的写法更优于minValue<i<maxValue的写法，这样更能强调你写判断的变量是什么。
P441 和0比较，写成显示而不隐式，写成while（done !=0）而不写成while（！done）。
P443 空语句有“这里不希望做任何事情”的意义。
P445 很少有人能理解3重以上嵌套IF语句，如果深层次的嵌套出现在循环里，你通常可以把循环体提取成子程序来加以完善。
P456对于三种标准的结构化编程结构之外的任何控制结构的使用—也就是说，使用break、continue、return、throw—catch——都要持一种批判的态度。
P458 决策点，if 、while、 and 、or 、case、 for。
P505 结构化基础测试，数据流测试，边界值测试，等价类划分，错误猜测，几类坏数据，几类好数据，测试本身的错误。
P552 修改代码之前保存备份以前的代码。
P553在不是完全理解代码的时候不要修改代码，（坚决否定“我不知道这段代码出了什么问题，我试试这样修改它，希望它有效果”这样的做法）。
P593 减少代码行数就能提升生成机器代码的速度，减少占用的资源这样的想法是错的。
P595 尽可能的使每个子程序的运行达到最快，最小。能使程序运行的时候最小最快是错误的，这样很可能会忙着优化无关紧要的子程序，而对整个系统全局性的优化点视而不见；
代码可移植的时候，在某个环境中提升性能的方法在其他环境中可能会损坏性能。
代码调整；
在不能正确运行出结果之前，不要要求程序更小巧或者运行更快。
P597 选择合适的编译器优化程序，得到的效果可能比用编写技巧的更好，花式的编译让编译器优化的时候痛苦不堪。
P598 常见的低效率资源
输入输出,能在内存中操作就不要在硬盘、数据库、或者跨网络操作；
分页，系统交换内存页面的运行速度比在同一页内低很多；
系统调用；
解释型语言。C/C++、visual basic、C#编译型；java字节码；PHP,Python；
错误，去掉了调试代码、忘了释放内存、数据库设计失误、轮询并不存在的设备。
P612 按出现频率来调整顺序。
P614 case语句或者if—then—else语句组开发环境不同，任何一种都有可能性能更高；
用查询表代替复杂表达式。
P617 循环内判断外提，提高性能的方法（慎用），不过和编程规范违背，有的时候代码可读性甚至比运行速度和占用资源更重要。
P617合并，展开循环。
P618 尽可能的使循环内部做更少的工作。
P623 把最忙的循环放在最内层，削减强度——用轻量级运算来代替一次高昂的运算。
P625 使用整数型而不是浮点数型，整数型的运算比浮点数型的运算快得多。
数组维度尽可能的少。
P628 缓存机制，把某些常用的值存起来，需要的时候直接从内存读取，而不需要重新从硬盘读取。
P628 代数恒等式，用低复杂度的操作代替高复杂度的操作，比如判断sqrt(x)>sqrt(y),只有当X>y时，才可能sqrt(x)>sqrt(y),编码时候直接用x>y代替。
P633 小心系统函数，系统函数往往提供极高精度的数据，相对的代价是系统函数运行非常非常的慢。不需要那么高的精度，就不要耗费时间去计算它。比如计算log以2为底的对数，但返回的是整形。
P635 使用正确的变量类型，好的编译器在编译期间就进行类型转换，然后赋值，不影响运行时候性能，差的编译器在运行时候才进行类型转换，严重影响运行性能。
预先计算出结果，存在表中或者数组中，需要的时候直接从表中或者数组中读取速度快的多。
P640 关键模块用低级语言重写代码。
P649—661 27章 程序规模对构建的影响（跳过）
P666需求变更和设计变更要成组控制和管理
P693增量集成（以核心为主，一个个集成）比阶段性集成（多个一起集成）更容易定位错误，改善对进度的监控，更加充分的测试各个单元。
集成方法：阶段式、增量、自上向下、自下向上、三明治、风险导向、功能导向、T型集成。
P711 编程工具，好的工具能让你舒服很多。
针对多个文件的查找和替换工具；
Diff工具——修改不同的文件比较器；
Merge工具，不允许多人同时修改同一个文件；
Source code beautifuler源代码美化器——使源代码格式统一；
Interface documentation接口文档生成工具。
P732能让好代码美观，使差代码难看的技术比那些让良莠不齐的代码看起来都很漂亮的技术更有用。
P732 布局技术：空白（分组/空行/缩进）、括号。好的风格适合大多数情况。
P755 单行语句布局：多用空格，过长语句换行运算符放首位结构更清晰（不完整明显标示原则）。
P758 每行仅写一条语句。
P762 尽可能的缩短变量的生存时间。
P787 代码注释指出代码解决的问题，而不是代码处理的方法。
P790 注释也要便于维护的风格。
P793 不要对单/多行代码做行尾注释。
P810 注释的一般原则：
说明文件的意图和内容；
将姓名、邮件和电话留在注释块中；
包含版本控制标记；
请在注释块中包含法律声明（版权声明）；
将文件命名成与其相关的名字。
后面还有三章，可能经历尚浅领悟不深，有兴趣的童鞋自己去读读吧。第33章：个人性格；第34章：软件开发艺术的有关问题；第35章：何处有更多信息。
第一篇随笔，不是技术性的东西，以后学成后再分享高深点的东西吧，还请多多指教。