内容简介 · · · · · ·
作者简介 · · · · · ·
目录 · · · · · ·
鸣谢
核对表目录
表目录
图目录
第1部分打好基础
第1章欢迎进入软件构建的世界
1.1什么是软件构建
1.2软件构建为何如此重要
1.3如何阅读本书
关键点
第2章用隐喻来更充分地理解软件开发
2.1隐喻的重要性
2.2如何使用软件隐喻
2.3常见的软件隐喻<批注15>
软件中的书法:写作代码
软件的耕作法:培植系统
软件的牡蛎养殖观点:系统生长
软件构建:建造软件
应用软件技术:智慧工具箱
组合各个隐喻
更多资源
关键点
第3章三思而后行:前期准备
3.1前期准备的重要性
前期准备适用于现代软件项目吗
准备不周全的诱因
关于开始构建之前要做前期准备的绝对有力且简明的论据
3.2辨明你所从事的软件的类型
迭代开发法对前期准备的影响
在序列式开发法和迭代式开发法之间做出选择
3.3问题定义的先决条件
3.4需求的先决条件
为什么要有正式的需求
稳定需求的神话
在构建期间处理需求变更
3.5架构的先决条件
架构的典型组成部分
3.6花费在前期准备上的时间长度
更多资源
关键点
第4章关键的“构建”决策
4.1选择编程语言
语言描述
4.2编程约定
4.3你在技术浪潮中的位置
“深入一种语言去编程”的例子
4.4选择主要的构建实践方法
关键点
第2部分创建高质量的代码
第5章软件构建中的设计
5.1设计中的挑战
设计是一个险恶的问题
设计是个了无章法的过程(即使它能得出清爽的成果)
设计就是确定取舍和调整顺序的过程
设计受到诸多限制
设计是不确定的
设计是一个启发式过程
设计是自然而然形成的
5.2关键的设计概念
软件的首要技术任务:管理复杂度
理想的设计特征
设计的层次
5.3设计构造块:启发式方法
寻找现实世界中的对象
形成一致的抽象
封装实现细节
当继承能简化设计时就继承
隐藏秘密(信息隐藏)<批注69>
找出容易改变的区域
保持松散耦合
查阅常用的设计模式
其他的启发式方法
关于设计启发的总结*****
使用启发式方法的原则
5.4设计实践
迭代
分而治之
自上而下和自下而上的设计方法
建立试验性原型
合作设计
要做多少设计才够?
记录你的设计成果
5.5对流行的设计方法的评论
更多资源
软件设计,一般性问题
软件设计理论
设计模式
广义的设计
标准
关键点
第6章可以工作的类
6.1类的基础:抽象数据类型
需要用到ADT的例子
使用ADT的益处
更多的ADT示例
在非面向对象环境中用ADT处理多份数据实例
ADT和类
6.2良好的类接口
好的抽象
良好的封装
6.3有关设计和实现的问题
包含(“有一个……”的关系)
继承(“是一个……”关系)
成员函数和数据成员
构造函数
6.4创建类的原因
应该避免的类
总结:创建类的理由
与具体编程语言相关的问题
6.6超越类:包
更多资源
关键点
第7章高质量的子程序
7.1创建子程序的正当理由
似乎过于简单而没必要写成子程序的操作
总结:创建子程序的理由
7.2在子程序层上设计
7.3好的子程序名字
7.4子程序可以写多长
7.5如何使用子程序参数
7.6使用函数时要特别考虑的问题
什么时候使用函数,什么时候使用过程
设置函数的返回值
7.7宏子程序和内联子程序
宏子程序在使用上的限制
内联子程序
关键点
第8章防范式编程
8.1保护程序免遭无效输入数据的破坏
8.2断言
建立自己的断言机制
使用断言的指导建议
8.3错误处理技术
健壮性与正确性
高层次设计对错误处理方式的影响
8.4异常
8.5隔离程序以免遭由错误造成的损害
隔离区与断言的关系
8.6辅助调试代码
不要自动地把产品版本的限制强加于开发版本之上
尽早引入辅助调试的手段
采用冒进式编程
计划移除调试辅助代码
8.7确定在产品代码中该保留多少防范式代码
8.8防范式编程时保持防范
其他资源
关键点
第9章伪代码编程过程
9.1创建类和子程序的步骤概述
创建一个类的步骤
创建子程序的步骤
9.2伪代码
9.3通过伪代码编程过程创建子程序
设计子程序
编写子程序
检查代码
收尾工作
根据需要重复上述步骤
9.4伪代码编程过程之外的其他方案
关键点
第3部分变量
第10章使用变量的一般事项
10.1数据认知
数据认知测试
有关数据类型的其他资源
10.2轻松掌握变量定义
隐式声明
10.3变量初始化原则
10.4作用域
使变量引用局部化
尽可能缩短变量的“存活”时间
减小作用域的一般原则
有关缩小变量作用域的说明
10.5持续性
10.6绑定时间
10.7数据类型和控制结构之间的关系
10.8为变量指定单一用途
关键点
第11章变量名的力量
11.1选择好变量名的注意事项
最重要的命名注意事项
以问题为导向
最适当的名字长度
变量名字的效果范围
变量名字中的计算值限定词
变量名字中的常用反义词
11.2为特定类型的数据命名
为循环索引命名
为状态变量命名
为临时变量命名
为布尔变量命名
为枚举类型命名
为常量命名
11.3命名规则的力量
为什么要有规则?
何时采用命名规则
正式程度
11.4非正式命名规则
语言无关规则的指导原则
语言相关规则的指导原则
混合语言编程的注意事项
命名规则示例
11.5标准前缀
用户自定义类型缩写
语义前缀
标准前缀的优点
11.6创建具备可读性的短名称
一般的缩写指导原则
语音缩写
有关缩写的评论
11.7应该避免的名称
关键点
第12章基本数据类型
12.1使用数的普遍规则
12.2整数
12.3浮点数
12.4字符和字符串
C中的字符串
12.5布尔变量
12.6枚举类型
如果你的语言里没有枚举类型
12.7命名常量
12.8数组
12.9创建你自己的类型(类型别名)
为什么创建自己的类型的示例是用Pascal和Ada写的?
创建自定义数据类型的指导原则
关键点
第13章不常见的数据类型
13.1结构
13.2指针
用来理解指针的例子
使用指针的一般技巧
C++指针
C指针
13.3全局数据
与全局数据有关的常见问题
使用全局数据的理由
只有万不得已时才使用全局数据
用访问子程序来取代全局数据
如何降低使用全局数据的风险
其他资源
关键点
第4部分语句
第14章组织直线型代码
14.1必须有明确顺序的语句
14.2顺序无关的语句
使代码易于自上而下的阅读
把相关的语句组织在一起
关键点
第15章使用条件语句
15.1 if语句
简单if-then语句
if-then-else语句串
15.2 case语句
为case选择最有效的排序
使用case语句的提示
关键点
第16章控制循环
16.1选择循环的种类
什么时候使用while循环
什么时候用带退出的循环
何时使用for循环
何时使用foreach循环
16.2循环控制
进入循环
处理好循环体
退出循环
检查端点
使用循环变量
循环应该有多长
16.3轻松创建循环——由内而外
16.4循环和数组的关系
关键点
第17章不常见的控制结构
17.1子程序中的多个返回
17.2递归
递归的例子
使用递归的技巧
17.3 goto
反对goto的论点
支持goto的观点
关于goto的虚假辩论
错误处理和goto
goto和在else子句中的共享代码
goto使用原则总结
17.4对不常见控制结构的看法
其他资源
关键点
第18章表驱动方法
18.1表驱动方法使用总则
使用表驱动方法的两个问题
18.2直接访问表
示例:一个月中的天数(Days-in-Month)
示例:保险费率
例子:灵活的消息格式(Flexible-Message-Format)
构造查询键值
18.3索引表访问(Indexed Access Tables)
18.4阶梯访问表
18.5表查询的其他示例
关键点
第19章一般控制问题
19.1布尔表达式
用true和false做布尔判断
简化复杂的表达式
编写肯定形式的布尔表达式
用括号使布尔表达式更清晰
理解布尔表达式是如何求值的
按照数轴的顺序编写数值表达式
与0比较的指导原则
布尔表达式的常见问题
19.2复合语句(块)
19.3空语句
19.4驯服危险的深层嵌套
对减少嵌套层次的技术的总结
19.5编程基础:结构化编程
结构化编程的三个组成部分
19.6控制结构与复杂度
复杂度的重要性
降低复杂度的一般原则
其它类型的复杂度
关键点
第5部分代码改善
第20章软件质量概述
20.1软件质量的特性
20.2改善软件质量的技术
开发过程
设置目标
20.3不同质量保障技术的相对效能
缺陷检测率
找出缺陷的成本
修正缺陷的成本
20.4什么时候进行质量保证工作
20.5软件质量的普遍原理
推荐读物
相关标准
关键点
第21章协同构造
21.1协同开发实践概要
协同构造是其他质量保证技术的补充
协同构造有利于传授公司文化以及编程专业知识
集体所有权适用于所有形式的协同构造
在构造前后都应保持协作
21.2结对编程
成功运用结对编程的关键
结对编程的好处
21.3正式检查
你期望检查能够带来什么结果
检查中的人员角色
检查的一般步骤
检查中的自尊心
检查和代码大全
检查总结
21.4其他类型的协同开发实践
走查
代码阅读
大型演示
协同构造技术的比较
参考资料
结对编程
检查
相关标准
关键点
第22章开发者测试
22.1开发者测试在软件质量中的角色.. 500
构造中测试
22.2推荐的开发者测试方法
先测试还是后测试
开发者测试的局限性
22.3测试技巧锦囊
不完整的测试
结构化的基础测试
数据流测试
等价类划分
猜测错误
边界值分析
几类坏数据
几类好数据
采用容易手工检查的测试用例
22.4典型错误
哪些类包含最多的错误?
错误的分类
不完善的构造过程引发错误所占的比例
你期望能发现多少错误
测试本身的错误
22.5测试支持工具
为测试各个类构造脚手架
Diff工具
测试数据生成器
覆盖率监视器
数据记录器/日志记录器
符号调试工具
系统干扰器
错误数据库
22.6改善测试过程
有计划的测试
重新测试(回归测试)
自动化测试
22.7保留测试记录
个人测试记录
推荐读物
测试
测试脚手架
测试优先的开发
相关标准
关键点
第23章调试
23.1调试概述
调试在软件质量中所扮演的角色
调试效率的巨大差异
让你有所收获的缺陷
一种效率低下的调试方法
23.2寻找缺陷
科学的调试方法
寻找缺陷的一些小建议
语法错误
23.3修正缺陷
23.4调试中的心理因素
心理取向如何导致调试时的盲目
“心理距离”在调试中的作用
23.5调试工具——明显的和不那么明显的.. 557
源代码比较工具
编译器的警告消息
扩展的语法和逻辑检查
执行性能分析器
测试框架
调试器
其它资源
关键点
第24章重构
24.1软件进化的类型
软件进化的哲学
24.2重构简介
重构的理由
拒绝重构的理由
24.3特定的重构
数据级的重构
语句级的重构
子程序级重构
类实现的重构
类接口的重构
系统级重构
24.4安全的重构
不宜重构的情况
24.5重构策略
推荐读物
关键点
第25章代码调整策略
25.1性能概述
质量特性和性能
性能和代码调整
25.2代码调整简介
Pareto法则
一些无稽之谈
何时调整代码
编译器优化
25.3蜜糖和哥斯拉
常见的低效率之源
常见操作的相对效率
25.4性能测量
性能测量应当精确
25.5反复调整
25.6代码调整方法总结
推荐读物
算法和数据类型
关键点
第26章代码调整方法
26.1逻辑
在知道答案后停止判断
按照出现频率来调整判断顺序
相似逻辑结构之间的性能比较
用查找表替代复杂表达式
使用惰性求值
26.2循环
将判断外提(Unswitching)
合并循环
展开
尽可能减少再循环内部做的工作
哨兵值
把最忙的循环放在最内层
削减强度
26.3数据变换
使用整型数而不是浮点数
数组维度尽可能少
尽可能减少数组引用
使用辅助索引
使用缓存机制
26.4表达式
利用代数恒等式
削弱运算强度
编译时初始化
小心系统函数
使用正确的常量类型
预先算出结果
删除公共子表达式
26.5子程序
将函数重写为内联
26.6用低级语言重写代码
26.7变得越多,事情反而更没变
推荐读物
关键点
第6部分系统考虑
第27章程序规模对“构筑”的影响
27.1交流和规模
27.2项目规模的范围
27.3项目规模对错误的影响
27.4项目规模对生产率的影响
27.5项目规模对开发活动的影响
活动比例和项目规模
程序、产品、系统和系统产品
方法论和规模
额外资源
关键点
第28章管理“构筑”
28.1鼓励良好的编码实践
设定标准的考虑事项
鼓励良好的编码实践的技术
本书的角色
28.2配置管理
什么是配置管理?
需求变更和设计变更
软件代码变更
工具版本
机器配置
备份计划
有关配置管理的额外资源
28.3评估“构筑”进度表
评估的方法
评估“构筑”的工作量
对进度的影响
评估与控制
如果你落后了该怎么办
有关软件评估的额外资源
28.4度量
有关软件度量的额外资源
28.5把程序员当人看
程序员们怎样花费时间?
性能差异与质量差异
信仰问题
物理环境
有关“把程序员当人看”的额外资源
28.6管理你的管理者
有关管理构造的额外资源
相关标准
关键点
第29章集成
29.1集成方式的重要性
29.2集成频率——阶段式集成还是增量集成
阶段式集成
增量集成
增量集成的益处
29.3增量集成的策略
自顶向下集成
自底向上集成
三明治集成
风险导向的集成
功能导向的集成
T-型集成
集成方法小结
29.4 Daily Build与冒烟测试
哪种项目能用daily build过程?
持续集成
额外资源
关键点
第30章编程工具
30.1设计工具
30.2源代码工具
编辑
分析代码质量
重构源代码
Version Control
数据词典
30.3可执行码工具
产生目标码
除错
测试
代码微调
30.4工具导向的环境
30.5打造你自己的编程工具
项目特有的工具
脚本
30.6工具幻境
额外资源
关键点
第7部分软件工艺
第31章布局与风格
31.1基本原则
布局的极端情况
格式化的基本原理
人和计算机对程序的解读
好布局有什么用?
把布局作为一种信仰
良好布局的目标
31.2布局技术
空白区
括号
31.3布局风格
纯块结构
模仿纯块结构
使用begin - end对(大括号)指定块边界
行尾布局
哪种风格最优?
31.4控制结构的布局
格式化控制结构块的要点
其他考虑
31.5单条语句的布局
语句长度
用空格使语句显得清楚
格式化后续行
每行仅写一条语句
数据声明的布局
31.6注释的布局
31.7子程序的布局
31.8类的布局
类接口的布局
类实现的布局
文件和程序布局
更多资源
关键点
第32章自说明代码
32.1外部文档
32.2编程风格作文档
32.3注释或不注释
32.4高效注释之关键
注释种类
高效注释
最佳注释量
32.5注释技术
注释单行
注释代码段
注释数据声明
注释控制结构
注释子程序
注释类、文件和程序
32.6 IEEE标准
软件质量保证标准
更多资源
关键点
第33章个人性格
33.1个人性格是否和本书话题无关
33.2聪明和谦虚
33.3求知欲
33.4诚实
33.5交流与合作
33.6创造力和纪律
33.7偷懒
33.8不像你想象中那样起作用的性格
矜持
经验
编程狂人
33.9习惯
更多资源
关键点
第34章软件开发艺术的有关问题
34.1克服复杂性
34.2精选编程过程
34.3为人写程序,其次才是为机器
34.4以所用语言编程,但思路不受其约束.. 843
34.5借助规范集中注意力
34.6基于问题域编程
将程序划分为不同层次的抽象
34.7“当心落石”
34.8反复,再反复
34.9不要顽固不化
判断
折中主义
试验
关键点
第35章何处有更多信息
35.1关于软件创建的信息
35.2创建之外的话题
综述资料
软件工程综览
其他注释过的参考书目
35.3期刊
初级程序员杂志
高级程序员杂志
专题出版物
35.4软件开发者的读书计划
入门级
熟练级
精通级
35.5参加专业组织
参考文献
索引
· · · · · · (收起)
"代码大全(第2版)"试读 · · · · · ·
CodeGear首席技术官(CTO) 李维——代码大全是我早在好几年前便已经阅读过的好书。这几年来我不知买过多少书籍,也清理过许多因为书房再也放不下的书籍,但是代码大全这本书始终占据着我书架上重要的位置而不曾移开过,因为好书是经得起时光考验的。 微软亚洲研究院 研究员 潘爱民——在众多的编程类书籍中,如果只让我挑一本书来阅读,那我一定选择《代码大全》,因为它是最不可或缺的..
豆瓣成员常用的标签(共406个) · · · · · ·
喜欢读"代码大全(第2版)"的人也喜欢 · · · · · ·
按有用程度 按页码先后 最新笔记
-
理想的设计特征
liuh (要加油!)
高质量的软件设计应该考虑如下目标,如果这些目标之间存在冲突,需要在其中进行折中,并得到一个最优的设计。 1.最小的复杂度 避免”聪明“但是却不容易理解的设计; 2.易于维护 软件的生命期更多的是维护阶段; 3.松散耦合 4.可扩展性 面向未来进行设计 5.可重用性 每一个项目都要为团队的积累做出贡献; 6、7high fan-in,low fan-out 每一个类应该力求被更多其他类使用; 每一个类应该力求使用最少的其他类,才能管... (更多)高质量的软件设计应该考虑如下目标,如果这些目标之间存在冲突,需要在其中进行折中,并得到一个最优的设计。1.最小的复杂度避免”聪明“但是却不容易理解的设计;2.易于维护软件的生命期更多的是维护阶段;3.松散耦合4.可扩展性面向未来进行设计5.可重用性每一个项目都要为团队的积累做出贡献;6、7high fan-in,low fan-out每一个类应该力求被更多其他类使用;每一个类应该力求使用最少的其他类,才能管理好复杂度;8.可移植性对需要在客户端运行的软件可能很重要,但对现在互联网而言,后台程序对这点的考虑可以降低优先级了;9.精简性把多余的代码都删掉,有冲动时问自己一个关键的问题”这虽然简单,但把它加进来之后会损害什么呢?“一个新近的好的例子:Redis作者拒绝微软的Windows补丁(http://blog.nosqlfan.com/html/3528.html)10.层次性力求能在任意层次观察系统,层次间互相隔离;11.标准技术每个项目应该力求引入最少的新技术; (收起)2011-12-20 16:23:27 2人收藏 回应
-
第53页
深山行 (天气真好,只要你微笑)
架构应该描述所有主要决策的动机。谨防“我们向来这么做”这种自认为有理的说法。有这样一个故事,Beth想按照她丈夫家祖传的广受好评的炖肉菜谱来做一锅炖肉。她丈夫Adbul说,他母亲是这样教他的:先撒上盐和胡椒,然后去头去尾,最后放到平底锅里盖上盖子炖。Beth就问了:“为什么要去头去尾呢?”Abdul回答说:“我不知道,我向来这么做。这得问一下我母亲。”他打电话给母亲,母亲说:“我不知道,我向来这么做。这得问一下你祖... (更多)架构应该描述所有主要决策的动机。谨防“我们向来这么做”这种自认为有理的说法。有这样一个故事,Beth想按照她丈夫家祖传的广受好评的炖肉菜谱来做一锅炖肉。她丈夫Adbul说,他母亲是这样教他的:先撒上盐和胡椒,然后去头去尾,最后放到平底锅里盖上盖子炖。Beth就问了:“为什么要去头去尾呢?”Abdul回答说:“我不知道,我向来这么做。这得问一下我母亲。”他打电话给母亲,母亲说:“我不知道,我向来这么做。这得问一下你祖母。”他母亲打电话问祖母,祖母回答说:“我不知道你为什么要去头去尾。我这么做是因为我的锅太小了装不下。” (收起)2011-04-08 19:41:36 回应
-
第268页
嘿咻复嘿咻 (超越一切的意志)
为布尔变量命名(发现自己有很多2b的命名) done,error,found,success。像这样的名字都具有很清晰的含义,因为其状态要么是true,要么是false,done=true表示已经完成了,done=false表示没完成。 而status这样的名字就是很2的命名,因为没有明确的true或者false。修改为statusOK 更好一点 有些程序员喜欢命名前面加上 Is,这样,变量名就变成了一个问题:isdone?isError? isFound? 用true或者false回答问题也就给该.. (更多)为布尔变量命名(发现自己有很多2b的命名)done,error,found,success。像这样的名字都具有很清晰的含义,因为其状态要么是true,要么是false,done=true表示已经完成了,done=false表示没完成。而status这样的名字就是很2的命名,因为没有明确的true或者false。修改为statusOK更好一点有些程序员喜欢命名前面加上 Is,这样,变量名就变成了一个问题:isdone?isError?isFound? 用true或者false回答问题也就给该变量作出了取值。优点:不能用于哪些模糊不清的名字 isStatus? (这算神码优点。。。)缺点:判断的时候2b了。比如: if(isFound) ,不如if(found)吧。发现我写的很多代码里就有。。。尽量使用肯定的布尔变量名。否定的名字有 notFound.notdone.notSuccessful .很难看有个2b的情况。如果要求反的时候 if not notFound 哈哈哈。太2了。。。 (收起)2011-12-12 20:31:47 回应
-
第3页
tyger (耐心、专注)
chp.1 Software Construction ——这一章作者解决了software construction所包含的内容,以及为什么要包含这些内容。 #Problem definition #Requirements development -Construction planning #Software architecture/High level design -Detailed design -Coding and debugging -Unit testing -Integration testing -Integration #System testing #Corrective maintenance #注释的为相关话题,本书中不作为重点... (更多)chp.1 Software Construction——这一章作者解决了software construction所包含的内容,以及为什么要包含这些内容。
#注释的为相关话题,本书中不作为重点讨论;其它内容被包括进construction。#Problem definition #Requirements development -Construction planning #Software architecture/High level design -Detailed design -Coding and debugging -Unit testing -Integration testing -Integration #System testing #Corrective maintenance
——这个应该不止,可能需要更详细的说明:比如同样的教育水平、同等的工作经历情况下的比较等。A classic study by Sackman, Erikson, and Grant showed that the productivity of individual programmers varied by a factor of 10 to 20 during construction (1968).
——这话实在,1、有些流程确实没必要;2、技术人员讨厌繁琐、无用的流程。所以工业上有时候就都简化了,但作者说的这些差不多是构建一个生产软件流程的最小集合了。 (收起)no matter how rushed or poorly planned a project is, you can’t drop construction.
2011-05-09 23:19:34 回应
-
理想的设计特征
liuh (要加油!)
高质量的软件设计应该考虑如下目标,如果这些目标之间存在冲突,需要在其中进行折中,并得到一个最优的设计。 1.最小的复杂度 避免”聪明“但是却不容易理解的设计; 2.易于维护 软件的生命期更多的是维护阶段; 3.松散耦合 4.可扩展性 面向未来进行设计 5.可重用性 每一个项目都要为团队的积累做出贡献; 6、7high fan-in,low fan-out 每一个类应该力求被更多其他类使用; 每一个类应该力求使用最少的其他类,才能管... (更多)高质量的软件设计应该考虑如下目标,如果这些目标之间存在冲突,需要在其中进行折中,并得到一个最优的设计。1.最小的复杂度避免”聪明“但是却不容易理解的设计;2.易于维护软件的生命期更多的是维护阶段;3.松散耦合4.可扩展性面向未来进行设计5.可重用性每一个项目都要为团队的积累做出贡献;6、7high fan-in,low fan-out每一个类应该力求被更多其他类使用;每一个类应该力求使用最少的其他类,才能管理好复杂度;8.可移植性对需要在客户端运行的软件可能很重要,但对现在互联网而言,后台程序对这点的考虑可以降低优先级了;9.精简性把多余的代码都删掉,有冲动时问自己一个关键的问题”这虽然简单,但把它加进来之后会损害什么呢?“一个新近的好的例子:Redis作者拒绝微软的Windows补丁(http://blog.nosqlfan.com/html/3528.html)10.层次性力求能在任意层次观察系统,层次间互相隔离;11.标准技术每个项目应该力求引入最少的新技术; (收起)2011-12-20 16:23:27 2人收藏 回应
-
第268页
嘿咻复嘿咻 (超越一切的意志)
为布尔变量命名(发现自己有很多2b的命名) done,error,found,success。像这样的名字都具有很清晰的含义,因为其状态要么是true,要么是false,done=true表示已经完成了,done=false表示没完成。 而status这样的名字就是很2的命名,因为没有明确的true或者false。修改为statusOK 更好一点 有些程序员喜欢命名前面加上 Is,这样,变量名就变成了一个问题:isdone?isError? isFound? 用true或者false回答问题也就给该.. (更多)为布尔变量命名(发现自己有很多2b的命名)done,error,found,success。像这样的名字都具有很清晰的含义,因为其状态要么是true,要么是false,done=true表示已经完成了,done=false表示没完成。而status这样的名字就是很2的命名,因为没有明确的true或者false。修改为statusOK更好一点有些程序员喜欢命名前面加上 Is,这样,变量名就变成了一个问题:isdone?isError?isFound? 用true或者false回答问题也就给该变量作出了取值。优点:不能用于哪些模糊不清的名字 isStatus? (这算神码优点。。。)缺点:判断的时候2b了。比如: if(isFound) ,不如if(found)吧。发现我写的很多代码里就有。。。尽量使用肯定的布尔变量名。否定的名字有 notFound.notdone.notSuccessful .很难看有个2b的情况。如果要求反的时候 if not notFound 哈哈哈。太2了。。。 (收起)2011-12-12 20:31:47 回应
-
第264页
嘿咻复嘿咻 (超越一切的意志)
变量名中常用的对仗词 begin / end first / last locked / unlocked min / max next / previous old / new opened / closed visible / invisible (这个没用过啊) up / down (更多)变量名中常用的对仗词begin / endfirst / lastlocked / unlockedmin / maxnext / previousold / newopened / closedvisible / invisible (这个没用过啊)up / down (收起)2011-12-12 20:26:00 回应
书评 · · · · · · (共83条) 我来评论这本书
热门评论 最新评论
软件构建的核心就是管理复杂度
-
- mijia(怪兽工程师) 啊,也不知道多少天了,终于啃完了大部头Code Complete。经典就是经典,确实受益匪浅。 总结一下,其实让我记忆深刻的主要是两点: 首先,软件构建的核心就是管理复杂度。虽然书中有不少的篇幅来讨论变量、语句等等这些编程的基本要素,还包括代码改善和调整的策略和方法,可谓不无巨细。不过深入理解一下,这些...... (14回应)2006-05-19 63/66有用
《代码大全》——软件开发的世界地图
-
- 庄表伟 我有很浓厚的“地图情结”,以前我写过一篇《我的信仰地图》,最近又做了一次关于Ajax的演讲,名字叫做《Ajax技术地图》。我一直以来的观点是,世界是一个整体,在这个巨大的世界之中,任何事物、任何知识,任何观点,都有其合理、自然的位置。理解这个世界的过程,就是逐步将需要了解的各种事物,在作为整体的一个世界中,找到其位...... (12回应)2006-05-05 32/40有用
代码大全中英文要点
-
- rocflytosky(曲突徙薪亡恩泽,焦头烂额为上客) 《代码大全》是一本不多见的值得多次阅读的好书,在《代码大全》一书中,每一章后面都有这一章的要点,略读这些要点中我们就可以了解到我们已经掌握了哪些知识,哪些知识还没有掌握,阅读,重读时就有重点了。下面列出这些要点,供没有购买这本书的同学(同仁)参考,或可用作决定“是否应该买这本书”的参考。 第1章 欢迎进入软件构建的世...... (12回应)2006-09-19 17/20有用
为编码人员写的一本书
-
- 泥土 适合有一定编码经历的程序员阅读。如果大部分章节涉及的问题你都没有感触,说明或者读者没一定编码经历,或者已经跨过了这个层次。对于后一种,就没有必要看了。但对于前一种读者,建议还是看看。看的方法上,不需要字斟句酌,关注其思想和方法就可以了。......2012-01-31
Code Complete, Second Edition
-
- 涅瓦纳(一个沉默的观影者与读书人) 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了......2011-07-30 来自 Microsoft Press版
代码大全
-
- 涅瓦纳(一个沉默的观影者与读书人) 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了......2011-07-30 来自 电子工业出版社2006版
china-pub近期免费赠书活动大汇总
-
- china-pub(网上书店) http://www.china-pub.com/STATIC07/1106/jsj_zengshu_110616.asp 1、china-pub新浪微博免费赠书(5本) #china-pub赠书#共5册, 《云计算核心技术剖析》 《云计算(第二版)》 《Linux内核设计与实现(原书第3......2011-06-17
"代码大全(第2版)"的论坛 · · · · · ·
| 代码大全--子程序 读书笔记 | 来自yolanda | 2009-07-20 | |
| 看这本书是一种享受 | 来自博文视点 | 2009-11-04 | |
| 圣经 | 来自何艳 | 2009-11-04 | |
| 这书适合刚工作的吗? | 来自Wu Jia-Yi | 4 回应 | 2010-09-12 |
| 《代码大全》已9次印刷,印数突破50000册 | 来自yolanda | 1 回应 | 2010-08-19 |
> 浏览更多话题
这本书的其他版本 · · · · · · ( 全部6 )
- Microsoft Press版 June, 2004 / 105人读过
- 电子工业出版社版 2006-12 / 93人读过 / 有售
- Microsoft Press版 14 May, 1993 / 13人读过
- 学苑出版社版 1993年11月 / 7人读过
以下豆列推荐 · · · · · · (全部)
- 豆瓣评分>9的书(100人以上) (阿獠)
- 各学科领域入门书籍 (征羽)
- 我的编程之路 (风中纸页)
- 程序员最应该读的图书(中译版) (hongqn)
- 所谓知识的另一种 (自娱者小五)
谁读这本书?
喜欢这本书的人常去的小组 · · · · · ·

- Vim (6192)

- Python编程 (19000)

- 程序员书屋 (6481)

- 博文视点交流组 (420)

- 程序员(不看公告发豆油的... (4662)

- 分享计算机书籍 (5288)

- 图灵之友 (1195)

- LISP (2009)
喜欢这本书的人关注的活动 · · · · · ·
订阅关于代码大全(第2版)的评论:
feed: rss 2.0













