代码大全核心checklist

软件开发流程和check list

测试条件：
在Sensor上安置好白屏光源调节曝光时间，颜色增益，使得画面呈现灰色，并确认整体
亮度在最高亮度的80%左右采集影像图片
Mean and Std
测试目的：
测试图片是否处于Middle Level
测试方法：
1.将图像分割为A，B两个区域，A区为图像中心25%区域， B区为图像周边区域
2）将每个通道分成M*N块数据块，并统计每块数据块的均值，记录数据Rmean[m*n],Bmean[m*n],Gmean[m*n]， ROG[m*n],BOG[m*n]
3）统计每个色块的均值最大及最小值，再求积，则得到每个色块的uniformity，作为测试数据
4）取出中心位置的ROGRef，BOGRef，再将m*n个ROG，BOG与 ROGRef，BOGRef进行比较，取差异最大值作为测试数据
高分辨率
低分辨率
对上图中大于10的亮度进行统计求和，再取自然对数，数值分别为：12.2311 和 10.1364
从而可指定标准区分出良品不良品。
Line Chart Histogram
测试方法：
按亮度绘出对应视场角图像的直方图统计两个波峰间的亮度所占的比例测试图像及对应直方图如下：
测试方法：
工作电流：通过对Die的寄存器进行设置，让其处于功耗最高的状态，测量其3路电源的电流。
待机电流：通过硬件或软件让Die进入待机状态，并调整 PWDN、RESET、MCLK、SDA、SCL的状态，调整AVDD、 DOVDD、DVDD的电压，让Die的功耗最低，测量总电流。
Middle Level Test
使用单位定义(3位字符)：
TSV事业部→TSV
WOC事业部→WLC

(完整word版)重点代码检查表

2.ServiceApplyDeal.saveApplyDealData（）服务申请处理信息必须包含环节实例ID，如果该值为空，抛出异常。（各开发人员调用此方法，请注意传入环节实例ID）
2、ServiceApplyDeal.saveApplyDealData（）服务申请处理信息必须包含环节实例ID，如果该值为空，抛出异常。（各开发人员调用此方法，请注意传入环节实例ID）
2、问题申请页面，选择服务类别未传busyflowtype参数
已修改
变更管理
叶海龙
王海峰
2006.08.28
2006.08.29
1.变更申请页面JSP需要调整, 注意与事件申请页面的不同
2、变更无服务等级, init_apply和view_apply方法需要去除查询服务等级的相关代码
正在修改
计划任务
正在修改
资产配置
叶海龙
王海峰
2006.08.28
2006.08.29
1.修改了AIB生成的DAO相关方法代码,破坏了对象的原子性操作。
2、直接调用DAO的方法,连接未释放,造成整个系统无法获取可用数据库连接
2.直接调用DAO的方法，连接未释放，造成整个系统无法获取可用数据库连接
2、直接调用DAO的方法，连接未释放，造成整个系统无法获取可用数据库连接
2.JSP页面嵌入太多业务逻辑代码，难以阅读，需要整理，放入JAVA类中
2、JSP页面嵌入太多业务逻辑代码，难以阅读，需要整理，放入JAVA类中
正在修改
由caseid找对应的关联, 应该综合考虑表relate_caseid的CASEID和RELATE_CASEID两个字段
2、ServiceApplyDeal.saveApplyDealData（）服务申请处理信息必须包含环节实例ID, 如果该值为空, 抛出异常。（各开发人员调用此方法, 请注意传入环节实例ID）

代码大全核心checklist

为了更好的评估代码写的哪里有问题，我把《代码大全》里核心的部分checklist整理出来了，大家可以大概过一遍，不一定每写完一个程序都要一条一条的去检查，但心里应该有这么一张检查表，在写代码和review代码时自然而然的想起来。

设计设计是否经过多次迭代，并最终决定了最好的一个？是否同时使用自上而下和自下而上的方法来解决设计问题？类与类之间的交互关系是否已经设计为最小化？设计被划分为层次吗？你对把这一程序分解成为子程序，包和类的方式感到满意吗？程序是不是易于维护？设计是否精简？设计出来的每一个部分都绝对必要吗？整体而言，你的设计是否有助于最小化偶然性和本质性的复杂度吗？类的设计你是否把程序中的类都看做是抽象数据类型了？是否从这个角度评估它们的接口了？类是否有一个中心目的？类的命名是否恰当？其名字是否表达了其中新目的？类的接口是否展现了一致的抽象？类的接口是否能让人清楚明白的知道如何用它？类的接口是否抽象，使你能不必顾虑他是如何实现其服务的？你能把类看做黑盒子吗？类提供的服务是否足够完整，让其它类无需动用其内部数据？是否已从类中去除无关信息？是否考虑过把类进一步分解？在修改类时是否维持了其接口的完整性？是否把成员的可访问性降到最小？是否避免暴露类的数据成员？类是否避免对其使用者，包括其派生类会如何使用它做了假设？类是否不依赖于其它类？它是松散耦合吗？继承是否只用来建立一个is a关系？派生类是否遵循了LSP原则。

继承层次是否很浅？类中是否只有大约七个或者更少的成员？是否把类直接或者间接调用其他类的子程序的数量减到最少？类是否在绝对必要时才与其他类写作？是否在构造函数中初始化了所有的数据成员？子程序创建子程序的理由充分吗？一个子程序中所有适合单独提出的部分是不是已经被提出到单独的子程序中了？过程的名字是否用了强烈、清晰的动词加宾语的词组，函数的名字是否描述了其返回值？子程序的名字是否描述它所作的全部事情？子程序是否具有强烈的功能上的内聚性？子程序之间是否有较松散的耦合？子程序与其它子程序之间的连接是否是最小的，明确的，可见的，灵活的？子程序的长度是否是由其功能和逻辑自然确定，而非遵循任何人为的编码标准？子程序的参数表是否表现出一种具有整体性且一致的抽象？子程序参数的排列顺序是否合理？是否与类似的子程序的参数排列相符？接口假定是否在文档中说明？子程序的参数是否没有超过7个？是否用到了每一个输入参数，是否用到了每一个输出参数？子程序是否避免了把输入参数用作工作变量？如果子程序是一个函数，那么它是否在所有可能的情况下都能返回一个合法的值？防御式编程子程序是否保护自己免遭有害输入数据的破坏？你用断言来说明编程假定吗？其中包括了前条件和后条件了吗？断言是否只说明从来不应该发生的情况？你是否在架构或者高层设计中规定了一组特定的错误处理技术？你是否在架构或者高层设计中规定了是让错误处理更倾向于健壮性还是正确性？代码中用到辅助调试的代码了吗？在防御式编程时引入的代码量是否适宜，既不过多也不过少？你在项目中定义了一套标准化的异常处理方案吗？如果可能的话，是否在局部处理了错误而不是把它当成一个异常跑出去？所有异常是否都与抛出他们的子程序在同一抽象层次上？每个异常是否包含了关于异常发生的所有背景信息？代码中是否没有空的catch语句？检查有害输入数据的代码是否也检查了故意的缓冲区溢出，SQL注入，HTML注入，整数溢出及其他恶意输入数据？是否检查了所有的错误返回码？是否捕获了所有的异常？出错消息中是否避免出现有助于攻击者攻入系统所需的信息？伪代码是否检查过已满足所有的先决条件？定义好这个类要解决的问题了吗？高层次的设计是否清晰？能给这个类和其中的每个子程序起一个好的名字吗？考虑过该如何测试这个类及其中的每个子程序吗？关于效率的问题，你主要从稳定的接口和可读的实现这两个角度考虑吗？还是主要从满足资源和速度的预期目标的角度考虑过呢？从标准库函数和其它代码库中寻找过可用的子程序或者组件吗？从参考书中查过有用的算法了吗？是否用详尽的伪代码设计好每一个子程序？你在脑海里检查过伪代码吗？这些伪代码容易理解吗？关注过那些可能让你重返设计的警告信息了吗？是否把伪代码正确的翻译成代码了？你反复使用伪代码编程过程了吗？在做出假定的时候有没有对它们加以说明？已经删除了那些冗余的注释了吗？你是否采取了几次迭代中最好的那个结果？还是在第一次迭代之后就停止了？你完全理解你的代码了吗？这些代码是否容易理解？变量变量声明位置靠近变量第一次使用的位置吗？尽可能在变量声明的同时初始化变量吗？计数器和累加器经过适当初始化了吗？如果需要再一次使用，之前重新初始化了吗？适当的重新初始化“需要重复执行的代码里的变量”了吗？代码在通过编译器编译的时候是不是没有警告信息？你启用了所有可用的警告信息了吗？如果语言允许隐式声明，你为由此可能引发的问题做好补偿措施了吗？如果可能，所有变量都被定义为具有最小的作用域吗？各变量的引用点都尽可能集中在一起吗？对同一个变量的两次相邻引用，或者变量的整个生命期都这样做了吗？控制结构符合数据类型吗？所有声明的变量都用了吗？变量都在合适的时间绑定了吗？也就是说你有意识的在晚期绑定所带来的灵活性和增加复杂度之间做出平衡了吗？每个变量都有且仅有一项用途吗？每个变量的含义都很明确且没有隐含含义吗？变量命名名字完整并且准确的表达了变量所代表的含义吗？名字足够长，可以让你无需苦苦思索吗？如果有计算限定符，它被放在名字后面吗？名字中用Count或者index来掉提Num了吗？循环小标的名字有意义吗？所有临时的变量都重新命名为更有意义的名字了吗？当布尔变量为真时，变量能准确表达其含义吗？枚举中的名字含有能够表示其类别的前缀或者后缀吗？具名常量是根据它所代表的抽象实体儿不是它所代表的数字来命名的吗？命名规则能够区分局部数据，类的数据和全局数据吗？规则能够区分类型名，具名常量，枚举类型和变量名吗？规则能够在编译器不强制检测只读参数的语言里表示出子程序的输入参数吗？规则能尽可能地与语言的标准规则兼容吗？名字为可读性而加以格式化了吗？是否避免只为了省一个字符而缩写的情况？所有单词的缩写方式都一致吗？名字能够读出来吗？避免使用容易被看错和读错的名字吗？在缩写对照表里对端名字做出说明了吗？基本数据类型代码中避免使用神秘数值了吗？代码考虑了除零错误了吗？类型转换很明显吗？如果一条语句中存在两个不同类型的变量，那么这条语句会像你期望的那样求值吗？代码避免了混合类型比较吗？使用整数除法表达式能按预期的那样工作吗？整数表达式避免整数溢出问题了吗？代码避免了对数量级相差具体大浮点数做加减运算了吗？代码系统地阻止了舍入错误的发生吗？代码避免对浮点数值做等量比较了吗？代码避免使用神秘字符和字符串了吗？使用字符串时避免了off-bye-one错误了吗？程序用额外的布尔变量来说明条件判断了吗？程序用额外的布尔变量来简化条件判断了吗？程序用枚举类型而非具名常量来提高可读性和可修改行了吗？当变量不能用true和false表示的时候，程序用枚举类型来取代布尔变量了吗？针对枚举类型的才测试检测了非法数值了吗？把枚举类型的第一项条目保留为“非法的”了吗？具名常量使用一致吗？没有在某些位置使用具名常量又在其他位置使用文字量？所有的数组下标都没有超出数组边界吗？数组引用没有出现off-by-one的错误吗？所有的多维数组的下标顺序都正确吗？在嵌套循环里，把正确的变量用于数组下标来避免下标错乱吗？不常见的数据类型你使用结构体而不是使用单纯的变量来组织和操作相关的数据吗？你考虑过创建一个类来代替使用结构体吗？所有的变量是否都是局部或者是类范围的？除非绝对有必要才是全局的？你对所有的全局变量都加以文档说明吗？避免使用伪全局数据，即被四处传递且含有杂乱数据的的巨大对象吗？用访问器子程序来取代全局数据了吗？把访问其子程序和数据组织到类里了吗？访问器子程序提供了一个在底层数据类型实现之上的抽象层吗？所有相关的访问器子程序都位于同一抽象层吗？把指针操作隔离在子程序里了吗？指针引用合法吗？或者指针有可能成为悬空指针吗？代码在使用指针之前检查它的有效性了吗？在使用指针所指向的变量之前检查其有效性了吗？指针用完后被设置为空了吗？就可读性而言，代码用了所有需要使用的指针变量了吗？链表中的指针是按正确的顺序加以释放的吗？程序分配了一片保留的内存后备区域，以便在耗尽内存的时候能够优雅地退出吗？是不是在没有其他方法可用的情况下最终才使用指针的？组织直线型代码代码使得语句之间的依赖关系变得明显吗？子程序的名字使得依赖关系变得明显吗？子程序的参数使得依赖关系变得明显吗？如果依赖关系不明确，你是否用注释进行了说明？你用“内务管理变量”来检查代码中关键位置的顺序依赖关系了吗？代码容易按照自上而下的顺序阅读吗？相关的语句组织在一起吗？把相对独立的语句组放进各自的子程序里吗？使用条件语句代码的正常路径清晰吗？if-then测试对等量分支的处理方式正确吗？使用了else字句并加以说明了吗？else字句用的对吗？用对了if和else字句，即没有把它们用反吗？需要执行的正常情况维护if而不是else字句里吗？if-then-else-if把复杂的判断封装到布尔函数里了吗？if-then-else-if先判断最常见的情况了吗？if-then-else-if判断包含所有的情况吗？if-then-else-if是最佳的实现吗？比Case语句还要好吗？case子句排序的有意义吗？case子句的每种情况操作简单吗？必要的时候调用了其它子程序了吗？case语句检测的是一个真实的变量，而不是为了滥用case语句而而刻意制造变量吗？默认字句用的合法吗？用默认字句来检测和报告意料之外的情况了吗？在c,c++和java里，每一个case的末尾有一个break吗？循环在合适的情况下用while循环取代for循环了吗？循环是由内到外创建的吗？是从循环的头部进入循环的吗？初始化代码是直接位于循环前面吗？循环是无限循环或者事件循环吗？阿德结构是否清晰？避免使用像for i = 1 to 9999这样的代码吗？如果这是一个c++,c或java中的for循环，那么把循环头留给循环控制代码了吗？循环使用了{}及其等价物来括上循环体，以防止因修改不当而出错吗？循环体内有内容吗？他是非空的吗？把内务处理集中地放在循环开始或者循环结束处了吗？循环像定义良好的子程序那样只执行一件操作吗？循环短的足以一目了然吗？循环的嵌套层次不多于3层吗？把长循环的内容提取成单独的子程序吗？如果循环很长，那么它非常清晰吗？如果这是一个for循环，那么其中的代码有没有随意修改循环下标值？是否把重要的循环下标值保存在另外的变量里，而不是在循环体外使用该循环下标？循环下标是序数类型或者枚举类型，而不是浮点类型吗?循环下标的名字有意义吗？循环避免了下标串话问题吗？循环是在所有可能的条件下都能终止吗？如果建立了某种安全计数器标准，循环使用了安全计数器了吗？循环的退出条件清晰吗？如果使用了break或者continue，那么它们用对了吗？不常见的控制结构每一个子程序都仅在有必要的时候才使用return吗？使用return有助于增强可读性吗？递归子程序中包含了停止递归的代码吗？子程序用安全计数器来确保子程序能停下来吗？递归只位于一个子程序里面吗？子程序递归深度处于程序栈容量可以满足的限度内吗？递归是实现子程序的最佳方法吗？它要好于简单的迭代吗？是否在万不得已的时候才使用goto？如果用了goto，是否仅仅处于增强可读性和可维护性呢？如果处于效率因素而使用的goto，那么对这种效率上的提升做出衡量并且加以说明了吗？一个子程序里最多只用了一个goto标号吗？所有的goto都向前跳转，而不是向后跳转吗？所有的goto标号都用到了吗？表驱动法你考虑过把表驱动法作为复杂逻辑的替代方案吗？你考虑过把表驱动法作为复杂继承结构的替代方案吗？你考虑过把表数据存储在外部并在运行期间读入，以便在不修改代码的情况下就可以改变这些数据吗？如果无法用一种简单的数组索引去访问表，那么你把计算访问键值的功能提取成单独的子程序，而不是在代码中重复地计算键值吗？一般控制问题表达式中用的是true和false，而不是1和0吗？布尔值和true以及false做比较是隐式进行的吗？对数值做比较是显式进行的吗？有没有通过增加新的布尔变量，使用布尔函数和决策表来简化表达式？布尔表达式是用肯定形式表达的吗？括号配对吗？在需要括号来明确的地方都使用括号了吗判断是按照数轴顺序编写了吗？如果适当的话，java中的判断用的是a.equals(b)方式，而没有用a==b方式吗？空语句表述得明显吗？用重新判断部分条件，转换成if-then-else或者case语句、把嵌套代码提取成单独的子程序、换成一种更面向对象的设计或者其他的改进方法来简化嵌套语句了吗？如果一个子程序的决策点超过10个，那么能提出不重新设计的理由吗？- 全文完 -。

软件编程规范总则CHECKLIST

要使用大小写与下划线混排的方式。
是[]否[]免[]
序
号
总则条款
执行情况
说明
4可读性
¹4-1：注意运算符的优先级，并用括号明确表达
式的操作顺序，避免使用默认优先级。
是[]否[]免[]
¹4-2：避免使用不易理解的数字，用有意义的标
识来替代。涉及物理状态或者含有物理意义的
常量，不应直接使用数字，必须用有意义的枚
功能简要说明。
是[]否[]免[]
¹2-3：源文件头部应进行注释，列出：版权说明、
版本号、生成日期、作者、模块目的/功能、主
要函数及其功能、修改日志等。
是[]否[]免[]
¹2-4：函数头部应进行注释，列出：函数的目的
/功能、输入参数、输出参数、返回值、调用关
系（函数、表）等。
是[]否[]免[]
¹2-5：边写代码边注释，修改代码同时修改相应
查及评审。
是[]否[]免[]
11代码测试、维护
¹11-1：单元测试要求至少达到语句覆盖。
是[]否[]免[]
¹11-2：单元测试开始要跟踪每一条语句，并观
察数据流及变量的变化。
是[]否[]免[]
¹11-3：清理、整理或优化后的代码要经过审查
及测试。
是[]否[]免[]
¹11-4：代码版本升级要经过严格测试。
¹7-11：用断言对程序开发环境
（OS/Compiler/Hardware）的假设进行检查。
是[]否[]免[]
¹7-12：正式软件产品中应把断言及其它调测代
码去掉（即把有关的调测开关关掉）。
是[]否[]免[]
¹7-13：在软件系统中设置与取消有关测试手段，
不能对软件实现的功能等产生影响。

代码审计工具Findbugs自动检查CheckList及配置方法

代码审计工具Findbugs自动检查CheckList及配置方法
代码审计工具Findbugs是一个应用比较广泛的开源代码审计工具，如果开发团队利用好了这个工具，能够很大程度上提高软件产品的安全性。

而且重要的是Free。

首先，介绍一下安全审计配置文件的位置，网上都没有这方面的资料，我自己找了几个小时才找到。

这个配置文件不在安装文件夹，也不再Eclipse软件的文件夹，而是在具体项目的工作空间workspace中，具体位置是：workspace\.metadata\.plugins\edu.umd.cs.findbugs.plugin.eclipse\.fbprefs。

（以点开始的文件夹，还这么多层目录，很隐蔽！！！）
这个文件中，选中要审计的项目其配置值会是“TURE”，配置为不审计的项会是“FALSE”。

我们可以通过在工作中逐渐确定哪些安全项一定要检查，哪些不需要检查，确定之后，整个开发团队使用同一个配置文件，从而实现标准化、自动化地审查开发团队的代码。

代码走查检查单

3
编码时间模块名称测试完成日期
代码走查
；
能。化为局部变量。系。英文单词和拼音混写。
用同样的名称。
为单位，Tab键为4个空格。
文件编码制表时间
□ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合
■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合 ■ 符合
4
。定义过的常量。
□ 不符合 □ 不符合 □ 不符合 □ 不符合
□ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合
■ 符合 ■ 符合 ■ 符合 ■ 符合
开至少两个Tab键。
的1/5~1/3。
段空一行；要描述。
□ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合 □ 不符合
□ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合 □ 基本符合

代码走读检查列表

代码走读检查列表Pre-review checklist 准备工作considerations 通常的考虑2.1Practical1.Have you been provided with a design document to understand the code ? Is the design documentup-to-date (latest version) ? 你是否得到一份解释代码的设计文档？设计文档是否最新的？2.Does the design document explain 设计文档是否做了如下解释：- program architecture ? 程序结构？- module breakup and functionality ? 模块是否已经完成和函数化？- task breakup ? 任务完成了吗？- each routine in pseudo-code form ? 每个函数都有伪代码？3.Has the code been compiled with strict warning and error checking enabled (-Wall and -Werroroptions); have all compilation warnings and errors been removed ? 代码是否已经被使用严格的告警和错误检查编译过？所有的编译告警和错误都已经修改？4.Has the code been compiled with a C++ compiler in addition to a C compiler ? 代码是否使用带C++特性的C编译器编译？2.2Program (product) architecture 程序结构1.Is the overall organization of the code clear, including a good architectural overview andjustification ? 所有代码的结构是否清晰，具有良好的结构外观和整齐？2.Are modules well defined, including their functionality and interfaces to other modules ? Is thetask/process breakup of the modules clear ? 所有的模块都定义得很好，包括函数和外部接口？任务/进程把模块分解清楚？3.Are all the functional requirements covered sensibly, by neither too few nor too many modules ?所有的功能需求都明显的覆盖，过多还是过少？4.Is the top-level design independent of the OS/environment which will be used ? 高层设计是否独立于OS/环境？5.Is the architecture designed to accommodate likely changes ? 结构设计是否能够满足变化？6.Does the architecture describe how reused code will be made to conform to other architecturalobjectives 体系结构是否描述了如何把代码重用到其他体系结构中?7.Does the whole architecture hang together conceptually ? 整个体系结构组合在一起，是否合理？8.Are all major data structures described and justified ? 所有主要的数据机构是否描述清楚和合理的9.Are data structures belonging to every module localised suitably so that they areaccessed/modified by well-defined access routines ? 模块中所有的数据结构是否都定义为局部的，并且通过定义好的函数进行访问？10.Is there a well-defined strategy to interface with external entities ? 是否为外部定义了良好的函数接口？11.Are all interfaces modularized so that changes will not affect the rest of the code ? 所有的接口是否模块化，因此他们的修改不影响其他代码？12.Are memory usage estimates and a strategy for memory management described and justified ? 内存使用方法和内存管理策略是否描述清楚和正确？13.Does the architecture set space and speed budgets for each module ? 体系构架是否对空间和速度都已经进行考虑？14.Is a strategy for handling data (strings) described and are storage estimates provided ? 是否提供了处理数据的策略？15.Is a coherent error handling strategy provided ? 是否具有同一的错误处理策略？16.Are error messages managed as a set to present a clean interface ? 是否把错误信息管理，作为一套清晰的函数接口提供？17.Are the motivations for the major decisions provided ?18.Are you (if you had to program/implement the system) comfortable with the architecture ? 你觉得这个体系结构舒服吗？3.Code Review Checklist for Standards 代码检查3.1 Directory organization 目录组织1.Are all file names less than or equal to 8.3 characters in length ? 所有的文件名是否小于或者等于8.3个字符？2.Are portable files identified as separate from core protocol files ? 可移植的文件是否和核心的协议文件分开？3.Is the file/module grouping clear ? 文件和模块是否分组清晰？organization 文件组织3.2File1.Does each file have a file header conforming to the standard convention ? 每个文件是否都有文件头和标准的习惯一致？（描述文件的用途，作者，对外提供的函数）2.Is each file organized in order - file header, type definitions, macros, prototypes, functions ? 每个文件都组织的有序－文件头，类型定义，宏，原型，函数？3.Are all lines within 80 characters in length ? 所有的代码行是否在80字符以内？4.Is each file less than or equal to 2000 lines in length ? 每个文件都小于2000行？5.Does each file hold code for one and only one module ? 每个文件是否只包含一个模块的代码？3.3Procedure organization / layout 函数组织1.Does each procedure have a header conforming to the standard convention ? 每个函数是否都有一个标准的函数头声明？2.Is the procedure organized - header, procedure name & parameters, procedure body ? 函数组织：头，函数名，参数，函数体3.Is the procedure defined in both ANSI format & otherwise using a __STDC__ compilation switch ?函数定义是否符合ANSI或者用标准C的编译开关？4.Does each procedure fit into a maximum of 2 printed pages (excluding the header) ? 每个函数都能够在最多2页纸可以打印。

代码大全

本书简介本书精选了《代码大全（第2版）》中的精华内容，包括各章“要点（Key Points）”以及“核对表（CHECKLIST）”的全部内容，便于读者在工作学习中随时查阅，极具参考价值。

另外，本书还附有《深入解析Windows操作系统，第4版——Microsoft Windows Server 2003/Windows XP/Windows 2000技术内幕》第14章的内容，供广大读者试读。

本书适合计算机相关专业学生和教师、软件开发人员、IT专业人员以及计算专业知识爱好者阅读和参考。

目录第1章欢迎进入软件构建的世界第2章用隐喻来更充分地理解软件开发第3章三思而后行：前期准备第4章关键的“构建”决策第5章软件构建中的设计第6章可以工作的类第7章高质量的子程序第8章防御式编程第9章伪代码编程过程第10章使用变量的一般事项第11章变量名的力量第12章基本数据类型第13章不常见的数据类型第14章组织直线型代码第15章使用条件语句第16章控制循环第17章不常见的控制结构第18章表驱动法第19章一般控制问题第20章软件质量概述第21章协同构建第22章开发者测试第23章调试第24章重构第25章代码调整策略第26章代码调整技术第27章程序规模对构建的影响第28章管理构建第29章集成第30章编程工具第31章布局与风格第32章自说明代码第33章个人性格第34章软件工艺的话题第35章何处有更多信息下载后点击此处查看完整内容。

check list的几大要素

Checklist的几大要素
Checklist的几个重要要素是：项目/任务、步骤、条件和标记（或勾选）方式。

1. 项目/任务：Checklist的首要要素是明确列出需要完成的项目或任务。

这些项目可以是工作任务、检查清单的事项、待办事项或需要遵循的步骤。

2. 步骤：每个项目或任务通常包含一系列需要执行的步骤。

步骤是指完成项目所需的行动或操作。

逐步明确列出这些步骤，可以确保在执行任务时不会遗漏关键细节。

3. 条件：Checklist的有效性还需考虑任务执行的条件。

条件是指完成项目或任务所需满足的先决条件、环境要求或其他相关情况。

在Checklist中包含适当的条件，有助于确保在适当的环境下执行任务。

4. 标记/勾选方式：Checklist的目的是跟踪任务完成情况。

为了实现这一目标，需要一种标记方式来记录已完成的步骤或任务。

常见的标记方式包括打勾、打对号、使用符号或颜色等方法。

这些要素的组合构成了一个完整的Checklist。

通过明确描述项目、步骤和条件，并使用适当的标记方式，Checklist 可以提供一个简单而有效的工具，帮助人们管理任务、确保重要步骤不被忽略，并提供一种可视化的方式来追踪任务的
进展。

Java编码规范-CheckList

可读性要求
代码结构性要求
异常处理
页面规范
数据库规范
大数据量处理：大数据量处理：需特别注意在Web前台一次从数据库获取大批量数据（列表查询无分页或在Web前台分页）；一次提交大批量数据量处理（如：导入）；在Web前台单次用户点击时后台执行很多次SQL（循环中执行SQL时注意）参数：参数：存储过程与函数体中传入参数的类型必须与数据库表字段的类型严格匹配，否则会造成索 by： order by：对大量数据进行order by操作会引发性能问题 DBLink： DBLink：和DBLink远程数据库大表关联存在性能问题
命 /** * 循环体说明：用于…… * 循环体起止条件: */
Java&JavaScript编码规范CheckList( Java&JavaScript编码规范CheckList(2-2) 编码规范CheckList
检查点检查要素
Import语句： Import语句：Import语句必须详细的写清楚具体的类，尽量避免使用 .* 语句。语句循环、分支层次: 循环、分支层次:不要超过5层，一个逻辑层中的函数调用深度不超过5层方法设计: 方法设计:理想情况下，方法应简明扼要。若长度很大，可考虑通过某种方式将其分割成较短的几个方法，便于检查及重用。避免：避免：尽可能少使用内部类、匿名类及抽象类，增强代码可读性。代码缩进：代码缩进： 1、利用缩进来显示程序的逻辑结构，缩进以Tab键为单位，定义Tab为 4个字节。 2、花括号对中后一个花括号，与相应的控制语句同列；(如for循环) 3、所有花括号中的程序体（包括局部变量定义等）都应在花括号的基础上缩进一个TAB的距离，注意不要使用空格缩进； 4、同一层次的条件语句应处在相同的列。(如if-else语句、try-catch-finally语句) 5、每条语句占一行。方法长度：方法长度：每个方法只实现一个功能；方法之间不要有较深的耦合；应控制在150行代码以内，循环体长度：应控制在50行代码以内，包括注释循环体长度： try-catch-finally： try-catch-finally：应控制在50行代码以内，包括注释处理位置：处理位置：一般情况下DAO、Service层可不处理异常，除非是特殊的Exception；不要在循环体内部try-catch而后不跳出循环，以免发生异常后还继续执行循环。处理要求：处理要求： 1、在有函数调用的语句，若该函数可能抛出异常，则就需要做try-catch。 2、不要捕捉但不处理异常(包括直接throw相同异常)，避免发生错误后继续执行后续代码。 3、应尽可能的处理预料到的异常，尽量不要使用异常机制来代替逻辑判断。 4、不要在循环体内部try-catch捕获异常后而不跳出循环，导致继续执行循环。 5、需要释放资源的操作，应在try-catch-finally语句的finally方法体中释放资源。日志：日志：影响程序执行的异常需要记录日志文件,应记录详细的异常日志和相关数据（足以进行错误分析：能定位到类和行），记录必须采用log.error()而不是info或者println; 用户提示：用户提示：捕捉到异常后，转换給用户的提示信息尽可能明确，提示信息不要写死在代码，应统一放在资源文件中，便于以后对消息进行修改。页面规范：页面规范：页面要符合页面规范（样式、对齐、字体、控件大小、间距等）客户端校验：客户端校验：浏览器端对用户输入数据的校验：是否可空校验、数据类校验型、数据范围校验、非法字符限制（防止出现SQL注入）服务端校验：服务端校验：服务器端对用户输入数据进行有效性校验（是否允许空、格式校验、规则校验），不能直接把可能有问题的数据直接给后端方法业务逻辑：业务逻辑：界面层只处理界面操作，使界面层代码尽量简单，业务逻辑应当尽量避免放入页面层缩进：缩进：页面要利用缩进来显示页面结构，缩进以Tab键为单位，定义Tab为 4个字节，尽量一行不超过三个页面元素。引入文件：引入文件：不要引入冗余的CSS、JS文件，页面图片大小要尽量小于50kb 数据库连接：应采用统一的获取连接及释放连接的公用方法，禁止手工创建连接。必须保数据库数据库连接：连接一定会被主动释放。（在try-catch-finally语句的finally段内释放或关闭数据库连接） SQL语句结构语句结构： SQL语句结构：SQL语句应有良好的可读性,不要出现很长或嵌套层次很深的SQL，嵌套子查询时，应尽量在内层过滤掉更多数据；复杂的SQL语句要写注释数据库事务：数据库事务：每次业务过程要保证数据库事务的一致性 select语句语句： select语句：要指明明确的字段，不使用select * from table，应使用：select c1, c2, c3 from t where …；在Oracle中要警惕使用for update语句造成锁表问题。 insert语句语句： insert语句：要指明明确的字段，不使用insert into table values()，应使用：Insert into t (c1, c2) values (v1, v2) 磁盘消耗：磁盘消耗：需警惕出现IO很高且耗时长SQL：导致系统整体性能下降出现大范围性能瓶颈(通常是一些后台JOB作业、数据库备份/恢复作业、复杂的统计查询等) 索引: 索引:需建立合适的索引，但索引过多也会导致性能下降。需警惕不能利用索引的典型语法： where字段上加函数或运算符；like ‘%***%’、not like、<> 、Not In、Not Exist、Is 表关联：表关联：需警惕不适当的大表关联等，如数据量特别大的表（这些表通常只允许查单个流程数据，不能用于表关联查询）

代码检视checklist

描述执行代码中不能出现中文传入的参数一般需要做合法性校验有返回值的函数一般需要做校验变量未实例化就使用业务异常处理与实际业务是否相符模块之间需要的参数不符合业务需求或者参数不匹配不允许空的语句块比对转换模块的指令是否与机器人指令文档的要求符合是否对全部指令进行转换查看代码实现业务是否与实际业务相符查看代码中日志消息等描述是否准确查找无效方法，删除没有使用的方法注释是否符合规范要求查看代码中的变量，类等命名是否符合规范要求查看代码中是否可以优化的部分，以简单优化为主一般要求整个系统中，同一意义的变量命名唯一或者类似检查代码对正常业务是否已实现检查代码对异常业务是否有处理检查服务端接口与客户端接口是否一致，实现的业务是否对应所使用的参数或对象未做判断是否为空
编号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
问题中文问题传入参数未校验函数返回值未校验变量未作实例化业务异常处理错误模块间参数不匹配空的else,catch语句指令转换模块是否转换符合要求指令转换模块是否完整业务是否符合要求代码中消息输出是否准确查找代码中的无效方法查看注释是否规范代码中命名是否符合规范检查代码中是否可以优化检查代码中同一意义的变量命名是否统一检视代码是否实现了正常业务检视代码是否对异常业务的处理检视服务端与客户端接口与业务是否统一空指针异常

Web 软件测试 Checklist 应用系列

| 2评论：图 2 的实例中，电子邮件地址为可选输入项，当用户没有填写该项时，产品提示需要输入邮件地址，而这与可选项的定义不符。

这是产品的一个缺陷。

图 3. 不合理的可选项输入设置图 3 的实例中显示为创建一个群组的窗口页面，该页面上唯一的输入即群组名称，而该群组名称作为群组的唯一标识，是应该为必填输入项的。

而这里，产品并未将该输入项作为必填项。

当用户不做任何输入，直接点击确定时，一个没有名字的群组将被创建。

这是不合理的，是产品的缺陷。

1.3 输入超过允许长度的数据正常情况下，每个输入域对输入数据的长度需要进行约束，给出最小长度和最大长度限制。

如果用户输入的数据长度超过最大允许长度，程序需要做出恰当处理。

例如，测试人员可以创建一个 1,000,000 字节或者更长的字符串，将该字符串输入到输入区域内，并继续后续操作，比如保存或者运行，看程序是否能够给出错误提示或者对字符串长度进行自动截断处理等操作。

1.4 页面装载或重装载后默认值当网页产品的页面装载完成以后，页面上显示的初始默认值，需要满足一致性和准确性。

一致性是指，每次从不同的路径到达相同页面后，在做进一步操作之前，页面默认值需要保持一致。

准确性是指，页面上的默认值需要布局合理，需要使能的按钮和操作都是可用的，需要被禁止的功能要确保不可用。

图 4. 初始加载页面图 4 显示的为打开一个用户配置文件页面，该页面打开后在不做任何更新的情况下，保存和取消按钮处于使能状态。

而实际上此时点击两图 5 的例子中，左侧图显示的是初始状态下组合框的列表内容，默认选择的是 Custom Group, 展开列表后可以看到 Search Results。

右如图 6 所示，在图中所示的表格中，不同组件的排列不齐，左边属性名称和右边的属性值输入域应该是水平对齐的。

这里是产品的一个缺如图 7 所示，注意红色圈内位置有一个未显示完全的按钮，其实下方还有其他更多内容，该部分内容已经超出显示区域的范围，应该在右如图 8 所示的例子中，当名字和姓氏都输入达到最大长度时，保存之后显示框中无法将两部分内容完整的呈现，并且没有水平滚动条辅助显示。

C++代码走查CheckList

C++代码⾛查CheckList
代码⾛查
⼀．代码⾛查的⽬的
1．保证代码符合编码规范
2．保证代码符合设计
3．发现bug
4．保证代码单元测试充分
5．促进开发⼈员之间的交流，为代码的优秀程度的提⾼和开发⼈员编码技能的提⾼提供契机。

⼆．过程
每次迭代都要对修改过和新编的代码进⾏⾛查，⾛查的过程如下图：
三．Checklist
说明：本checklist⽤于⾛查⼈员⾛查代码。

开发⼈员⽤于⾃我检查的checklist可以参照此checklist，依⾃⾝实际情况制定。

说明：本checklist应随着组织开发过程中出现的实际情况，对检查项具体内容进⾏增、删、改，以使得此checklist更具效率，但要注意保持检查项数⽬的简洁。

类名：⾛查的类的名字。

代码自查checklist

代码走读原则
一：准备工作
结论（是/否）
1：目录层次结构是否遵循标准？
2：流程图是否清晰？是否能从流程图判断该模块的结构？
3：注释文档是否清晰完全？
4：readme文档是否遵循标准？
5：是否可在模拟器上运行？
二：程序结构：的操作是否单独封装在一个文件,与gui解耦？
5：输出参数是否合理？
6：在保证代码清晰的前提下，函数是否使用了最少数目的return语句，除非不可以？
7：是否有重复代码？或者相似的代码可以分离出来？
8：你觉得这个函数看起来舒服吗？
四：变量
结论（是/否）
1:变量的命名是否完全的、明确的描述了该变量代表什么？
2:程序是否使用了特别的、易误解的、发音相似的命名？
9：每个文件是否只包含一个模块的代码？
10：文件的命名是否可以体现出该文件的作用？
11：你觉得这个体系结构舒服吗？
三：函数检查
结论（是/否）
1：函数的名字是否清晰的定义了它的目标以及函数所做的事情？
2：函数是否高内聚只做一件事情，并做好？
3：函数中的语句是否都在同一个抽象级上？
4：函数的参数是否合理，能否尽量控制在3个以内，必要时可以超过3个；
3：配置文件的操作是否单独封装在一个文件,与gui解耦？
4：涉及的独立的算法是否单独封装在一个文件,与gui解耦？
5：每个窗口界面是否单独封装在一个文件？
6：.c必须用相应的.h给外部引用函数、数据、对象等
7：所有代码的结构是否清晰，具有良好的结构外观和整齐？
8：所有的模块都定义得很好，包括函数和外部接口？
3:是不是所有的变量都有最小的活动范围？
五：注释
结论（是/否）

【开发部】代码CheckList

对于新作成表单必、新作成函数、新作成文件必须遵守以下规约： No 分类 1 分层原则/Service类 2 分层原则/Service类 3 分层原则/Service类 4 分层原则/Service类 5 分层原则/Service类 6 分层原则/Service类 7 分层原则/Dao类 8 分层原则/Dao类 9 分层原则/Dao类 10 分层原则/Dao类 11 Java
12 Java
13 Java
14 Java 15 16 17 18 19 20 Java Java Java Java Java J必须遵守以下规约： Check point Service类处理业务逻辑、不能含有SQL语句 Service类的public函数必须以"do"开头、只有一个参数、参数类型 Hashtable、参数名inputData、返回值类型Hashtable或HashMap。（适用于dwr） Service类不允许出现未经说明的 //TODO Service类声明Dao类，均在私有属性中声明或创建 Service类 import未使用到的类，不应存在实现某接口，但部分方法不实现，应在方法体中抛出未实现异常（ng.UnsupportedOperationException）或注释说明 Dao中不含业务逻辑、只负责数据存取（如角色权限判断、当前用户判断等）一个表对应一个Dao、Dao命名与表名一致禁止使用connect、preparedstatement、callablestatement、 ResultSet等对象直接操作数据库。 Dao层代码不允许有html标签，不允许出现业务逻辑，仅作为SQL拼装和执行异常捕获后、如不是业务有需要进行往下执行、则必须往外抛异常。每个Java文件必须有以下形式的文件头注释： /** * 版权所有：华信软件 * 项目名称:上海移动项目第三期 * 创建者: Wangdf * 创建日期: 2009-12-3 * 文件说明: 工单服务类 */ 每个Java函数的前面必须有以下形式的注释： /** * 工单编制表单初始化 * @param inputData 初始化参数 * @return 初始化显示后台数据 * @author wangdf */ 每个Java函数的全局成员变量必须有以下形式的注释： /** 业务ID */ public String appId = ""; 常量名必须是全大写的、单词与单词间加"_". 变量名必须小写字母开头、每个单词的开头字母大写。类名必须是大写开头、每个单词的开头字母大写。方法名必须是小写字母、动词开头，后面每个单词的开头字母大写。左大括号"{"必须在条件行的结果、不能在单独行。禁用System.out.输出日志，用日志组件进行日志输出常量的定义： A、可归类的常量需要有相关的常量类定义，使用时从常量类中获取，如部门ID，角色ID等 B、不可归类的常量，使用时需要在service类中以final类型定义

代码检查列表

1、代码的注释与代码是否一致?注释是否是多余的?
2、是否存在超过3层嵌套的循环与/或判断?
3、变量的命名是否代表了其作用?
4、所有的循环边界是否正确?
5、所有的判断条件边界是否正确?
6、输入参数的异常是否处理了?
7、程序中所有的异常是否处理了?
8、是否存在重复的代码?
9、是否存在超过20行的方法?
10、是否存在超过7个方法的类?
11、方法的参数是否超过3个?
12、是否有多种原因导致修改某个类?
13、当发生某个功能变化时，是否需要修改多个类?
14、代码中的常量是否合适?
15、一个方法是否访问了其他类的多个属性?
16、某几项数据是否总是同时出现，而又不是一个类的属性?
17、switch语句是否可以用类来替代?
18、是否有一类的职责很少?
19、是否有一个类的某些属性或者方法没有被其他类所使用?
20、在类的方法中是否存在如下的调用形式：a.b().c()?
21、是否某个类的方法总是调用另外一个类的同名方法?
22、是否某个类总是访问另外一个类的属性与方法?
23、是否两个类完成了类似的工作，使用了不同的方法名，却没有拥有同一个父类?
24、是否某个类仅有字段和简单的赋值方法与取值方法构成?
25、是否某个子类仅使用了父类的部分属性或方法?。

代码评审清单

代码评审清单（Code Checklist ）产品,项目组名称；_宅急送_________ 产品项号名称，公共_______________ 版本号：被检杳人簽字：—检杳內容: _ _检查人螯宇，_____________________ 检查日期’______________________说明：是杏尽童避免了嵌会的立•弔篦杂芳雄是否併行了必茅而充分的汗释拎K是否代码拥亍路径是否清晰S罰Chi航是否有決4分支控制逻短复杂度是否合浬是否诜行了必更1门充分的注释同个循坏怎是吞仅执行了羊而明确的巧毙占械比校需要挣常数玫在比较表达式的前面否代彳礎丧奸格ig化并能疝苴逻辑结枸尽量孑哎在循开丙岀观近程谐月奇个吐务可作远程谓用次数是否小于以冈1中因数是吞仕抱定范围内Joinb on矽页产恪匹0己问題淸单.冋幅沐阚窟改n期修改n期楡杳SQL r 是冈1语句』碍弓用乎符画单引号T^MO select *开预的语句，必姦指出旦饶宇SF严禁使用ins«t m2 Uiblc: values "t ? , ? , "?) ＞必须指1岀具依更0jt值広字段避兌隐含的炎型转换(不同数据类型字段明加)子宣询前后必须加上桔号邀免在我here使用，1* / 1=2’这*怯廿戎作为部分条件禁上使用椰图禁上使用XX in 0 or XX血CKm中的元素个数不应超过500)禁止使用or超辽500个其止使用not in・建议使冃not exist婪止在一条河语句中恃月3层以丄的嵌套如具勺多表连莪盯「应该有主从之分，尽重从一个表取数Where子句过滤条杵，索引列或过遞记录最多氏条林应験在前面字符邑连接必须使用“ rCaw when吾匀中巳能出珂二、k、u以及is mill运算袴左连接写送必須带”cxuei'关佬宰伝稈诅用蓟摇伎端启否有不必萼的冗輛摇Java代码审查检查丧类定义缺陷(CD)代码评申检査表软件代码检杳单（C语言）77 检鱼寮量和宏，数字帘金应该用宏未表不，检登宏足义中的数位、実型是合正佚月说明・1.本檢杳单为软件评頁朋检査较件产品惜俣和扶陷提供了指导。

集成测试CheckList

集成测试CheckList一、信息录入及选择：1. 所有输入框1) 必填项：必填项不输就保存应提示。

非必填项不输保存不应报错或提示。

（那些是必填项由开发提供）2) 字符长度：a) 输入超过字段规定长度的内容保存时应有提示；b) 输入框不做长度的限制，可以无限输入下去，根据数据库中对字符串长度的规定提示用户超长。

例：数据库中规定长度为20，输入了30个字符，这时页面需要检验错误，并提示用户同时把光标放在错误的输入框中c) 在输入时就限制输入长度的，对于同时可以输入英文和中文的地方，中英文的长度应对应1：2或1：3（UTF-8），例：有时限制可输入100个字符，可输入100个英文也可输入100个中文，但保存后中文内容无法保存到数据库中造成数据丢失。

3) 字符类型：在数据库中规定了字段类型，如果输入错误的字段类型是无法保存到数据库中的，造成数据丢失；在需求规定也会规定某些输入框的字段类型（数据库是都可以输入的），这时输入不符合需求的字段类型也应有提示，例如：只能输入数字的地方输入字母和中文、只能输入英文的地方输入中文，都应提示；有规定格式的输入框输入不符规定的内容应提示，如：电子邮箱的格式。

4) 空格：首尾空格应自动去除不进入记录；某些字段中间应该可以输入空格字符，例如：中英文姓名5) 特殊字符：规定不允许输入特殊字符处输入特殊字符，操作时应提示。

（那些是特殊字符由开发提供）6) 唯一性：字段应该唯一的输入重复记录保存应提示。

（那些字段需要检查唯一性，有开发提供）2. 某些操作单击即可，双击可能会报错。

例如：因为网络延时，对一条信息提交了几次（因环境原因此类测试比较难以实现，在测试时可以结合数据唯一性校验同时测试）3. 单选框：如单选组中未设默认值的，没选择内容就进行下一部操作，应提示；有默认值的只有正常流程。

4. 多选框：如果此复选框为必填项，则没有选择内容就进行下一步的操作，应提示去选择；如果不是必填项，不会出现提示5. 下拉框：1) 必须有内容2) 不可以手工输入3) 需要有ALL选项,除非特例,特例须讨论后决定4) 有连动关系的下拉框A下拉框选择后B下拉框内容才能显示并进行选择,例：选择了品牌才能看到品牌下的车型5) 有连动关系的下拉框修改：A下拉框选择后B下拉框选择值，之后A修改内容，B原来的选择以及可选择项应自动清除，可选择内容自动修改为A现选择项的对应内容，并显示相应默认值。