《代码大全checkpoint》由会员分享，可在线阅读，更多相关《代码大全checkpoint（7页珍藏版）》请在金锄头文库上搜索。
1、软件中的设计软件中的设计1.你尝试用多种方案来分解系统以确定是最佳方案吗？ 2.为了解决某些特定问题，你的系统中的风险部分或者不熟悉的部分创建过原型，写出 过数量最少的可抛弃的代码吗? 3.你的设计方案经过别人检查了吗？ 4.你一直在展开设计，知道实施细节跃然在纸上了吗？ 5.你的设计大家都能明白吗 ？ 6.使用了 UML 等标准技术是大家都清楚？ 7.你的设计被分为层次吗？ 8.你对把这一程序划分为包，类，子程序的方式满意吗？ 9.类与类之间的互交关系是否已设计为最小化了？ 10. 类和子程序是否被设计为能够在其他系统中重用？ 11. 设计是否精简，每一部分都绝对必要吗？ 12. 程序是否易
2、于维护？基本数据类型基本数据类型1.代码中避免使用神秘数字,和神秘字符串吗? 2.类型转换都是显示转换吗? 3.避免了混合类型的比较了吗？ 4.编译时的警告信息考虑到了吗？ 5.使用数据的时候考虑数据溢出问题了吗？ 6.避免浮点数做等量比较了吗？ 7.程序用额外的布尔变量来简化复杂的条件判断了吗？ 8.程序用枚举类型而非具名变量来提高可读性，可靠性，和可修改性了吗？ 9.返回值，参数用枚举了吗？ 10. 数组是否检查了没有 off-by-one 错误？ 11. 你有自己的数据类型吗? 12. 是否有将数据类型集中管理？ 13. 是否考虑当想关联的数据组织在一起变为一个结构体或者是类？变量名的力
3、量变量名的力量1.变量名是否直击问题域，没有有关计算机的处理的信息？ 2.变量名的名字是否知名见意？ 3.变量名是否有关于数据类型的前缀？ 4.是否将状态变量命名了一个比 flag 更好的名字 采用具名常量或者枚举代替了吗？ 5.临时变量怎么命名的？6.使用肯定的 bool 变量名了吗？没有 IS之内的命名？done found success 7.变量名是否没那么抽象而是直截了当的说明变量的本质？不常见的数据类型不常见的数据类型1.变量命名是否能把全局数据，类数据分开？g_ m_ 2.对全局数据是否有文档说明？ 3.使用访问器子程序取代全局数据了吗？ 4.指针操作隔离在子程序中了吗？ 5.是
4、不是在没有办法的情况下才使用指针的？ 6.在代码使用之前检查指针的可用性了吗? 7.使用结构体或者类代替一组有关联的数据类型了吗?使用变量的一般事项使用变量的一般事项1.变量声明的同时初始化了吗？（防御式编程） 2.在尽可能靠近第一次使用变量的位置定义和初始化变量了吗？ 3.在可能的情况下使用 final 或者 const 了吗？ 4.在构造函数里初始化类成员数据了吗？ 5.看到编译器的警告信息了吗？ 6.变量引用点跨度是否小？ 7.是否尽量缩短了变量的存活时间？ 8.在循环开始之前再去初始化该循环里使用的变量，而不是在该循环所属的子程序开始 处初始化这些变量。 9.引用点都集中起来在相关的语
5、句一起了吗？ 10. 变量值的绑定时间是否延迟，具备灵活性？编码期，编译期，加载期，对象实例化时？11. 变量用途是否单一？可以工作的类可以工作的类1.你是否把程序中的类都看做 ADT 了？是否从这个角度评估他们的接口了？ 2.类是否有一个中心目的？名字是否恰当？ 3.类的接口是否展现了一致的抽象？ 4.类的接口是否是可编程的？语意是否清晰明了？ 5.类的接口是否足够抽象，使你不用考虑它是如何实现服务的？你能把类看成黑盒吗？ 6.类提供的服务是否完整？ 7.是否从类中出去了无关的信息？ 8.是否考虑把类进一步分解成组件类？ 9.类的成员可见性是否尽量小？10. 类是否避免了对其使用者，包括其派
6、生类会如何使用它作出了假设？ 11. 继承是否是 IS/A 的关系？ 12. 类的文档中是否描述了其继承策略？ 13. 继承层次是否浅？ 14. 是否将类直接调用或者间接调用的类的子程序数量减少到最少了？ 15. 类是否在构造函数中初始化了所有的数据成员？ 16. 类的职责单一吗？创建类的原因创建类的原因1.为现实世界中的对象建模 2.为抽象的对象建模 3.降低复杂度 4.隔离复杂度 5.隐藏实现细节 6.限制变动的影响范围 7.隐藏全局数据 8.让参数传递更顺差 9.建立中心控制点 10.让代码重用 11.为程序族做计划创建子程序的理由创建子程序的理由1.降低复杂度 2.引入中间的，易懂的抽
7、象 3.避免代码重复 4.支持子类化 5.提高移植性 6.简化复杂的逻辑判断 7.隐藏实现细节 8.限制变化带来的影响 9.隐藏全局数据 10. 形成中央控制点 11. 达到特定的重构目的组织直线型代码组织直线型代码1.子程序的名字使得依赖关系变得明显吗？ 2.子程序的参数使得依赖关系变得明显吗？3.将相关语句组织在一起了吗？ 4.把相对独立的语句放在各自的子程序中了吗？使用条件语句使用条件语句1.首先写正常路径，再处理不常见的情况了吗？ 2.确保正常路径是清晰的了吗？ 3.确保等量的分支是正确的吗？ 4.case 子句中的 defalut 合法吗？ 5.使用默认子句来检测和报告意外情况了吗？
8、 6.把复杂的判断封装在 bool 函数调用中了吗？使用控制循环使用控制循环1.尽量保持循环简单了吗？ 2.内务操作代码用隔离了吗？ 3.循环下标命名合理吗？ 4.循环是从内到外建立的吗？ 5.从循环头部进入循环的吗？ 6.初始化代码直接位于循环前面吗？ 7.循环好像定义子程序一样只执行了一种操作吗？ 8.把长循环的内容提取成单独的子程序了吗？ 9.循环的退出条件清晰吗？ 10. 循环下标名字有意义吗？协同构建协同构建1.你是否有一个核对表，能让评论人员注意力集中在曾经发生过的问题的领域？ 2.你是否考虑定制某些场景，以帮助评论员在准备工作的时候集中注意力？ 3.是否每次详查都把发现的错误数据
9、收集起来，使你能调整本组织以后使用的核对表调试调试1.在动手之前先理解程序，理解整个程序而非局部问题？ 2.治本而不是治标 3.只有到理由充分的时候才修改代码 4.添加单元测试来暴露代码中的缺陷5.你是否避免采用随机尝试查找错误或迷信式的调试方法？ 6.在构造假设时考虑到所有可用数据？ 7.你是否利用了更好的调试工具？ 8.每次调试的时候将问题集中于一点吗？ 9.分而治之各个击破？ 10. 你和其他人一起讨论了吗？有忏悔式调试？ 11. 你的休息是否足够，确保你大脑清晰。 12. 用记事本，将要尝试的事情意义列出来 13. 用不同的方式重现错误 14. 你思考的细节是否完整严谨？ 15. 是否
10、抛开一切用足够的勇气面对问题？重构重构数据级的重构数据级的重构用具名常量代替神秘数字 用更明确或更具信息量的名字来重命名变量 将表达式内联化 用函数来代替表达式 引入中间变量 变量用途单一 使用局部变量来实现局部用途而不是使用参数 将基础数据类型转化为类 将一组类型码转换为类或者是枚举类型 将一组类型码转换为含派生类的类 将数组化为对象 用数据代替传统记录语句级的重构语句级的重构分解布尔表达式 将复杂的布尔表达式转换为命名精确的布尔函数 将条件语句中的不同部分中的重复代码合并 使用 break 或 return 而不是循环控制变量 在嵌套的 if then else 语句中一旦知道结果就立刻退
11、出而不是仅仅赋一个返回值 用多态来代替条件语句 创建并使用空对象代替对空值的检测子程序级的重构子程序级的重构提取子程序 将子程序代码内联化 将很长的子程序转换为类 使用简单算法代替复杂算法 增加参数，减少参数 将查询操作和修改操作区分开来 合并相似的子程序用参数来区分他们 通过传递不同的参数是子程序体现不同的功能 传递整体而非特定成员 传递特定成员而非整体 封装向下转型操作类实现的重构类实现的重构将值对象转换为引用 将引用转换为值对象 用数据初始化来代替虚函数 将特定代码提出生成派生类 将相似的代码合并到基类类接口的重构类接口的重构将某成员子程序放在另一个类中 将类分解 删除某个类 去掉中间人
12、 用委托代替继承 用继承代替委托 引入外部子程序 引入扩展类 封装暴露在外成员 对不能修改的去掉 SET 函数 封装不会用到的成员函数系统级的重构系统级的重构为无法控制的数据创建明确的索引源 将单向关联的类改为双向关联 将双向关联的类改为单向关联使用工厂函数而不是简单的构造函数 用异常代替错误代码，或者反其道而行之个人性格个人性格个人性格和编程能力有直接影响。 最有关系的性格为：谦虚，求知欲，诚实，创造性，和纪律，以及高明的偷懒 出乎意料的是，小聪明，经验，坚持和疯狂既有帮助也有害。 很多程序员不愿主动吸收新知识和技术，只依靠工作时偶尔接触的新信息。如果你能 抽出少量的时间来阅读和学习编程知识要不了多久就你就能鹤立鸡群。 要成为好的程序员，先要养成良好的习惯，其他自然水到渠成。
