代码检查表
(完整word版)重点代码检查表
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)
代码评审检查表模板
不适用 优秀 合格 不合 格
10 11 12 13 建议:
备注
Hale Waihona Puke 代码评审检查表 序号1 2 3 4 5 6 7 8
9
检查项 是否存在不可执行码和冗余码? 注释说明是否完整? 程序逻辑是按照需求的吗? 是否存在内存泄露或死锁? 算法执行是否正确? 变量定义是否合理? 最大,最小数据值的边界充分吗? 可移植性被考虑了吗? 当Bug修改时, 是否有充足的注释说明: 1. 变更作者 2. 变更日期 3. Bug号 4. 相关联files,source代码 编码标准和规则被遵照了吗? 是否进行了一致性校验: 所有文件(设计、需求说明 、 项目计划, SCM 计划、SQA计划、测试计划等) 是否被 更新以和最新的代码保持一致, 特别当有设计或需求变 动? 该项工作的计划与实际成本是否合理? 该项工作的计划与实际进度是否合理?
代码走查检查表
整个代码体系结构组合合理,分层清晰,代码之间功能划分明确
5
所有的接口模块化,尽量减少接口之间的耦合度,修改时尽量不影响其他代码模块
6
代码体系构架对空间和速度都已经进行考虑
7
数据库操作、IO操作等是否正确关闭资源。并且必须在try -catch-finally 的finally中关闭。
8
一个业务如果进行多次数据库更新、添加、删除是否正确添加事务。
9
进行逻辑与、逻辑或判断时是否使用短路与、短路或。
10
多处使用相同代码时,应定义唯一方法或变量以供使用。
11
对象是否使用工厂获取。
12
导入类时,如果仅使用包中的几个类,应导入具体类,而不是导入整个包。
13
数组声明的时候使用 int[] index ,而不要使用 int index[]。
14
代码实现的逻辑是否与详细设计描述的逻辑一致
21
异常要统一处理,异常处理方法是否符合项目组的约定
22
在Action中不要过多的逻辑处理代码
23
不要出现魔鬼数字
24
检查可能出现空指针异常的地方,例如一个对象可能为空,却调用它的方法或属性。
25
显示的文本无拼写和语法错误
26
所有的表达式使用了正确的操作符
函数组织
1
所有的函数名都小于64个字符
2
函数高内聚 尽量只做一件事情,并做好
7
复杂的表达式具备可读性,添加注释说明,表达式结构清晰
8
续行缩进
9
括号在合适的位置
10
每个顺序的小块用空行隔开
11
注释和代码对齐或接续在代码之后
12
JSP必须不能有basepath。
代码验收条件检查表
验收文档 代码说明文档 操作手册 部署文档
交付方所编写的需求文档、设计文档、功能清单、业务流程图(可包含在设计文档)、业务 架构图(可包含在设计文档)、开发帮助手册、部署安装配置手册等项目过程文档,详情见 附件“项目内验所需资料V1.0.doc”。 必须包括所提交的代码地址、代码清单和模块结构说明、代码的说明(各工程间的关联、运 行顺序、运行环境配置等)等信息,以doc或pdf格式提供,参考“附件6:代码结构说明文档 示例.docx”。
事项
是否符合
代码验收条件检系统,系统包括的功能及功能的说明,功能清单必须覆盖系统的所有功能。 功能清单以Excel表格的方式提供,参考“附件3:系统功能清单参考示例.xlsx”。
性能指标
根据合同要求,所明确的相关性能指标,若合同中无要求,参照我司与业主的合同等相关确 认文件作为指标。性能指标以doc或pdf格式提供。
项目所有功能有明确的操作说明,接收方或用户可根据操作手册完成操作。
包括开发环境部署文档、测试环境部署文档及生产环境部署文档。
以上事项必须全部符合。
测试用例
交付方所进行测试的所有测试用例,作为交付方执行测试工作的依据,以doc或pdf格式提 供,参考“附件5:系统测试用例示例.docx”。
测试报告
交付方所编写的测试报告且报告中明确结果:测试通过(功能测试、性能测试等),作为交付 方已完成自检并未检出问题的依据,以doc或pdf格式提供,按“附件4:系统测试报告模 版.doc”模版编写。
车辆售前检查表PDI
检查序号: 车辆编号 发动机号 车型代码 检查日期 车辆颜色 合格证号 车型名称 □顶灯、车内灯、行车照明灯 □行车照明灯开关 □危险警告灯 □防雾灯 □仪表板灯(全部) □牌照灯(全部) 检查所有灯光 □遮阳板/内视镜灯 □尾灯 □后备箱/货舱区灯 □转向信号指示灯 □警示灯(机油压力、预热、电瓶、驻车制 动及制动液位、水分离器、冷却水位) 检查控制结构 □音响、时钟设定和收放机功能 □空调控制结构(驾驶座、乘客做、后座)(暖风机 、空调器、除霜器) □门锁(手动、电动) □发动机舱盖、后备箱盖、后舱盖/尾门和燃油箱 盖打开装置(电动、手动) □喇叭 □转向柱锁定 □点烟器 □倒车镜 □驻车制动器 □座椅安装完好性 □安全带(前后) □靠背插销 □车门开启正常 □空调工作状况 □电瓶完好 □制动管路不漏油 检查发动机舱盖 □风扇及空调皮带紧张力 下的机构功能 □电气装置、导线及真空接头软管的磨损 □发动机运转状况(静态发动) □燃油管路不漏油 □变速器润滑油不渗漏 □前后桥润滑油不渗漏 □对正前大灯 □检查车门、发动机、后备箱盖和尾门检查 □检查所有钥匙 □检查所有地毯、车内附件 □检查车轮螺母拧紧情况 外观总体检查 □前保险杠下部机件状况 □彻底清洗车内外 □检查漆面 □提供保修手册、使用说明书、合格证 □检查风挡和车窗(侧、后部)(电动、手动) □检查随车工具 □已摘除雨刮护套 技术(检查)人员 客户: 试车 □变速器操作性能正常 冷热启动正常 □仪表(水温、机油压力、燃油、里程表、车速表) 显示正常 □离合器功能 □转向和动力转向正常 □加速性能 □空调及通风控制结构正常 □制动功能 检查和加注油液 □发动机冷却液 □发动机机油 □动力转向液 □制动液 □轮胎/胎压(包括备胎)的规格及破损 □前后风挡清洗液(冬季使用添加剂) 年 月 日 底盘号 所在库位
代码评审标准与结果
注释对于理解代码是否有帮助
7
代码中的注释是否充分
8
代码中的注释是否过多
布局/封装缺陷
1
代码布局风格和缩排标准是否前后一致并体现其逻辑结构
2
代码中是否存在已被注释且不再使用的代码
3
复杂程序是否合理地分解成多个子程序
4
每个方法的代码量是否都不超过60行
5
方法或类之间是否具有低耦合性
6
方法或类之间是否具有高内聚性
2
比较运算符是否正确
3
布尔表达式是否通过内部否定操作进行了简化
4
每个布尔表达式是否都正确
5
比较操作是否存在不引人注意的副作用
6
是否存在“&&”替换为“&”或“||”替换为“|”的情况
7
代码中是否避免了对浮点型数值的相等比较操作
流程控制缺陷
1
每个循环是否选用了最佳循环结构
2
所有的循环结束条件是否明显
3
6
注释对于理解代码是否有帮助
7
代码中的注释是否充分
8
代码中的注释是否过多
布局/封装缺陷
1
代码布局风格和缩排标准是否前后一致并体现其逻辑结构
2
代码中是否存在已被注释且不再使用的代码
3
复杂程序是否合理地分解成多个子程序
4
每个方法的代码量是否都不超过60行
5
方法或类之间是否具有低耦合性
6
方法或类之间是否具有高内聚性
7
是否存在重复代码且它的功能可以通过调用其他方法实现
8
方法参数数量是否控制在5个以内
性能/算法缺陷
1
是否存在更好的数据结构和算法可以采用
铁路货物运输品名分类与代码表
附件一铁路货物运输品名分类与代码表“铁路货物运输品名分类与代码表”、《铁路货物运输品名检查表》编制使用说明一、编制说明(一)编制原则1.以GB7635—87国家标准《全国工农业产品(商品、物资)分类与代码》为基础标准,参照国家统计局颁布的《货物运输量分类目录》,遵循国家分类标准的基本原则,结合铁路运输生产经营的特点和行业管理的需要。
2.以货物的自然属性、生产特征为主要分类标志,个别按用途归类。
同时考虑货物的国民经济意义、运量大小、运送条件和运价的要求。
3.适当照顾当前管理水平,兼顾历史资料的衔接与可比性以及运价现状和改革的需要,并留有扩展余地。
4.与国家标准和相关标准兼容。
(二)结构与编码“铁路货物运输品名分类与代码表”(以下简称分类与代码表)横向结构由代码、货物品类、运价号和说明四部分组成。
《铁路货物运输品名检查表》(以下简称检查表)横向结构由代码、拼音码、品名、整车运价号、零担运价号五部分组成。
货物品类分大类、中类、小类和细目四个层次。
大类、中类为运价、运输统计、计划、财务等使用的统一的货物品类名称。
小类是判定运价号、建设基金号和保价费率号的依据。
细目即品名,由部统一颁发,并以货物运输品名检查表形式对外公布。
其中大、中、小类在分类与代码表中列示,细目在检查表中列示。
代码采用7位数字码,相应分四个层次,由高位到低位,第一、二两位为大类码,第三位为中类码,第四位为小类码,第五、六、七位为品名码。
分类与代码表中只列示前四位。
在第一、二、三层次一般都设有收容类目,大类收容类目为“其他货物”用代码99表示,中、小类的收容类目“其他××”用末位为9的代码表示。
如果下一层次的类目不再细分时,在其代码后面补0。
各层次均留有适当空码,以备补充、调整。
同一小类内品名按品名的汉语拼音字头顺序编码。
“说明”栏是对各该品类的内容、特征、相互交叉事项和计费规定的必要提示和解释。
(三)货物名称与拼音码1.列入检查表的货物名称即细目,也称品名,采用通用、标准名称,包括具体名称和概括名称,除明定者外,一般不分形态、品种、商标、产地、规格、型号、用途、新与旧、完好与废次、天然与人造。
软件项目代码检查表
66
印。应该将异常记入日志或者包装后向上层抛出。对于 表现层页面,不应该出现程序异常,应该在捕获到异常
强制
后进行友好的提示。
67
对于静态方法,应该使用类名去使用,不应该用实例去 引用,主要是为了体现更多的语义。
强制
68
对一些基本数据类型和不太可能通过继承进行扩展的 类,应声明为readonly,提高效率。
强制
3
书写规范
修改源代码时,应尽量保持与所修改系统的编码风格保 持一致。
强制
4
命名规范 所有命名空间名称必须使用ESSE前缀。
强制
5
应该使用VS2005默认格式规范。
强制
6
一个C#源文件.cs应该只包含一个类,内嵌类和匿名类除 外。把所有枚举变量集中定义到同一个源文件中。
强制
7
命名空间的引用应该按照相关性进行分组。
28
进行外部访问。如果成员函数仅为自己和派生类使用, 强制
使用protected,如果仅仅为类本身访问,使用private。
29
命Байду номын сангаас空间应该使用Pascal命名方式,不要出现下划线等 符号,名词用有意义的缩写或者英文单词。
强制
30
所有类命名使用Pascal表示方式,使用名词组合。
强制
31
接口命名使用字母 “I” 加上 Pascal 形式的表示方式。
强制
15
循环变量应靠近循环体初始化。
强制
版本号:2 修订号:0
C#代码规范 缺陷描述
第1页 共6页
16
避免长的布尔表达式,应该换成多个更容易理解的表达 式。
强制
17
代码缩进,应该使用4个空格为一个单位进行缩进。
代码互检表模板
代码互检表模板
在软件开发过程中,代码互检是一个非常重要的环节,可以帮助发现潜在的错误,提高代码质量。
以下是一个简单的代码互检表模板,可以根据实际情况进行修改和扩展。
代码互检表
问题编号:__________
检查日期:__________
检查人员:__________
1. 代码风格与规范
是否遵循了统一的代码风格?
是否使用了合适的命名约定?
是否遵循了正确的缩进和空格规范?
是否使用了注释来解释代码的功能和意图?
2. 代码质量
是否存在重复的代码?
是否存在潜在的逻辑错误?
是否存在未使用的变量或函数?
是否存在性能问题?
3. 错误处理
是否正确处理了异常和错误?
是否使用了断言来验证代码的正确性?
是否对可能失败的操作进行了适当的检查?
4. 安全性
是否考虑了安全性问题?
是否使用了安全的函数和操作?
是否对用户输入进行了适当的验证和清理?
5. 其他注意事项
是否使用了第三方库或框架?是否遵循了其最佳实践?是否进行了必要的单元测试和集成测试?
是否对代码进行了备份或版本控制?。
代码检查列表
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、是否某个子类仅使用了父类的部分属性或方法?。
手术操作分类代码国家临床版2.0
腹内血管血管内压力测量 肠系膜血管血管内压力测量 肾血管内压力测量 外周静脉内压力测量 髋关节置换修复术,双髋臼和股骨成分 全髋关节假体翻修术 髋关节置换修复术,髋臼成分 髋关节髋臼假体翻修术 髋关节置换修复术,股骨成分 髋关节股骨假体翻修术 人工股骨干和股骨头修复术 髋关节修复术伴仅髋臼衬垫置换和(或)股骨头 髋关节髋臼衬垫和股骨头翻修术 髋关节髋臼衬垫翻修术 髋关节股骨头翻修术 人工股骨头修复术 髋轴面,金属与聚乙烯 髋轴面,金属与金属 髋轴面,陶瓷与陶瓷 黑金股骨头 髋轴面,陶瓷与聚乙烯 髋轴面,陶瓷与金属 膝关节置换修复术,全部(所有成分) 全膝关节假体翻修术 膝关节置换修复术,胫骨成分 膝关节胫骨假体翻修术 膝关节置换修复术,股骨成分 膝关节股骨假体翻修术 膝关节置换修复术,股骨成分伴胫骨(衬垫)置入 膝关节置换修复术,髌骨成分 膝关节髌骨假体翻修术 全膝关节置换修复术,胫骨置入(衬垫) 膝关节胫骨衬垫翻修术 髋关节表面置换,全部,髋臼和股骨头 全髋关节表面置换术 髋关节表面置换,部分的,股骨头 股骨头表面置换术 髋关节表面置换,部分的,髋臼 髋臼表面置换术 与供者有血缘关系的活体移植 与供者无血缘关系的活体移植 从尸体上移植 手术中神经生理监测 脑池穿刺 小脑延髓池穿刺术 经以前植入导管的脑室穿刺 经脑室分流导管脑室穿刺术 其他颅的穿刺 脑室穿刺术 前囟门穿刺术
00.5500x015 00.5500x016 00.5500x017 00.5501 00.5502 00.5600 00.5601 00.5602 00.5700 00.5800 00.5900 00.5900x003 00.5901 00.5902 00.6000 00.6000x001 00.6100 00.6100x008 00.6100x012 00.6101 00.6102 00.6200 00.6200x005 00.6201 00.6202 00.6300 00.6300x005 00.6300x006 00.6300x007 00.6301 00.6400 00.6400x009 00.6400x012 00.6400x013 00.6401 00.6500 00.6500x008 00.6500x010 00.6501 00.6502 00.6600 00.6600x004 00.6600x008 00.6700 00.6701 00.6800 00.6800x001 00.6900 00.6900x001 00.6900x002
最新代码检查表
2.3没有使用任何实例类成员(包括方法和成员变量)的方法是否被声明为静态的?
2.4异常发生时,记录错误日志是否存在使用System。out.println而不是日志模块记录日志的情况发生?
2.5参数、变量等的类型是否定义的合适?精度是否足够?方法的返回值是否定义恰当?
2.6使用已有设计模式时,该模式要求的技术细节是否实现正确、完整?
序号
检查项
检查结果
(Y/N/NA)
问题描述
1.
命名、注释及风格
1.1文件、类/接口、静态变量、成员变量、方法及关键代码是否都有格式良好、简明扼要、的注释?注释是否是对设计思路的说明而不仅仅是代码行为的描述?是否存在过时的注释或废代码注释?
1.2文件中各种段落布局是否合理、是否用恰当的空行分隔?代码的断行、对齐、缩进、空行是否恰当?
22嵌套内部类是否超过2检查项检查结果ynna问题描述23没有使用任何实例类成员包括方法和成员变量的方法是否被声明为静24异常发生时记录错误日志是否存在使用systemoutprintln是日志模块记录日志的情况发生
代码检查表
JAVA
代码检查表
北京东和盛达科技有限公司
模块名称:版本号:
检查时间: 检查员:
3.3是否避免了直接抛出Exception类异常,而没有抛出恰当的由Exception派生的异常类?
3.4try catch的结构是否合理?catch语句处理是否恰当?异常转抛时是否携带了嵌套异常?
3.5打开的流、连接等资源是否在finally语句块或恰当的地方关闭或释放了?临时资源使用完后是否及时释放了?如临时文件要及时删除。各种资源释放的顺序是否正确?
5.
目录结构
代码检查表
代码行注释量是否大于20%
设计者
检查者
1
2
3
4
5
6
7
8
9
10
11
12
备注
四、软件安装文件、固件烧录文件生成说明
□固件□软件(涂黑符号□标识)
提供软件安装文件打包说明、固件目标文件转烧录文件过程说明。
五、软件母盘制作、固件烧录过程说明
□固件□软件(涂黑符号□标识)
提供软件母盘刻录说明、固件烧录过程说明。
六、代码注释及语法检查表
□固件□软件(涂黑符号□标识)
序号
源码文件名称
4
5
6
7
8
9
10
11
12
备注
二、应用程序、目标文件清单
□固件目标文件□软件应用程序(涂黑符号□标识)
序号
文件名称
基本功能、配置描述
缺少次文件现象
问题解决人
1
2
3
4
5
6
7
8
9
10
11
12
备注
三、程序构造环境及编译说明
□固件□软件(涂黑符号□标识)
提供工具软件、路径设置、选项设置、配置文件、编译过程等说明。
项目名称、研发阶段
检查表编号
拟定质控协调员
检查表版本
项目负责人(提交人)
提交时间
部门负责பைடு நூலகம்(审阅人)
审阅时间
修改记录:
修改对象及内容
备注(原因、进一步说明)
修改人
修改时间
一、固件、软件模块开发卷宗
□固件模块□软件模块(涂黑符号□标识)
序号
模块名称
12、代码缺陷检查表示例
C/C++代码缺陷检查表 代码缺陷检查表示例§ § § § § § § § § 文件结构 程序的版式 命名规则 表达式与基本语句 常量 函数设计 内存管理 C++ 函数的高级特性 类的构造函数、析构函 数和赋值函数 § 类的高级特性 § 其它常见问题文件结构§ § § § § § 头文件和定义文件的名称 头文件和定义文件的目录结构 版权和版本声明 预处理块 头文件中只存放“声明”而不存放“定义” ……#ifndef GRAPHICS_H #define GRAPHICS_H #include <math.h> … #include “myheader.h” … void Function1(…); … class Box { … }; #endif// 防止graphics.h被重复引用// 引用标准库的头文件 // 引用非标准库的头文件 // 全局函数声明 // 类结构声明程序的版式§ § § § 空行 代码行内的空格 长行拆分 “{” 和 “}” 的使用if (year >= 2000) if(year>=2000) if ((a >= b) && (c <= d)) if(a>=b&&c<=d) for (i = 0; i < 10; i++) for(i=0;i<10;i++)// 良好的风格 // 不良的风格 // 良好的风格 // 不良的风格 // 良好的风格 // 不良的风格§ 一行代码是否只做一件事 § if、for、while、do等语句自占一行,不 论执行语句多少都要加“{}”。
JAVA代码审查检查表
11
3.2变量是否已经在定义的同时初始化
是[ ]否[ ]免[ ]
12
3.3类属性是否都执行了初始化
是[ ]否[ ]免[ ]
13
3.4代码段落是否被合适地以空行分隔
是[ ]否[ ]免[ ]
14
3.5是否合理地使用了空格使程序更清晰
是[ ]否[ ]免[ ]
15
3.6代码行长度是否在要求之内
是[ ]否[ ]免[ ]
16
3.7折行是否恰当
是[ ]否[ ]免[ ]
17
4.1包含复合语句的{}是否成对出现并符合规范
是[ ]否[ ]免[ ]
18
4.2是否给单个的循环、条件语句也加了{}
是[ ]否[ ]免[ ]
19
4.3if/if-else/if-else if-else/do-while/switch-case语句的格式是否符合规范
5
2.2复杂的分支流程是否已经被注释
是[ ]否[ ]免[ ]
6
2.3距离较远的}是否已经被注释
是[ ]否[ ]免[ ]
7
2.4非通用变量是否全部被注释
是[ ]否[ ]免[ ]
8
2.5函数是否已经有文档注释
是[ ]否[ ]免[ ]
9
2.6特殊用法是否被注释
是[ ]否[ ]免[ ]
10
3.1每行是否只声明了一个变量(特别是那些可能出错的类型)
是[ ]否[ ]免[ ]
20
4.4单个变量是否只做单个用途
是[ ]否[ ]免[ ]
21
4.5单行是否只有单个功能(不要使用;进行多行合并)
是[ ]否[ ]免[ ]
22
软件编程规范检查表-模板
2
3-2:命名中若使用特殊约定或缩写,则要有注释说明。
是[ ]否[ ]免[ ]
3
3-3:对于变量命名,禁止取单个字符(如i、j、k...),建议除了要有具体含义外,还能表明其变量类型、数据类型等,但i、j、k作局部循环变量是允许的。
是[ ]否[ ]免[ ]
4
3-4:命名规范必须与所使用的系统风格保持一致,并在同一项目中统一,比如采用UNIX的全小写加下划线的风格或大小写混排的方式,不要使用大小写与下划线混排的方式。
是[ ]否[ ]免[ ]
6
2-6:注释的内容要清楚、明了,含义准确,防止注释二义性。
是[ ]否[ ]免[ ]
7
2-7:避免在注释中使用缩写,特别是非常用缩写。
是[ ]否[ ]免[ ]
8
2-8:注释应与其描述的代码相近,对代码的注释应放在其上方或右方(对单条语句的注释)相邻位置,不可放在下面,如放于上方则需与其上面的代码用空行隔开。
1
2-1:一般情况下,源程序有效注释量必须在20%以上。
是[ ]否[ ]免[ ]
2
2-2:说明性文件(如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等)头部应进行注释,注释必须列出:版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等,头文件的注释中还应有函数功能简要说明。
是[ ]否[ ]免[ ]
3
2-3:源文件头部应进行注释,列出:版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。
是[ ]否[ ]免[ ]
4
2-4:函数头部应进行注释,列出:函数的目的/功能、输入参数、输出参数、返回值、调用关系(函数、表)等。
PDI检查表及手势
检查中发现的不合格项及处理结果
第 2 页共2 页
桑塔纳灯光检查标准手势
1、示宽灯
目的:检查前部小灯、后部小灯牌照灯功能是否齐全有效。
手势:双臂平伸,手指指大灯方向。
2、雾灯
目的:检查雾灯功能状态是否正常。
手势:双臂向前平伸,双手握拳,拇指向下。
3、右转向灯
目的:检查右转向灯功能状态是否正常。
手势:(前)左臂平伸,五指张开并拢示意灯光闪动。
(后)右臂平伸,五指张开并拢示意灯光闪动。
4、左转向灯
目的:检查左转向灯功能状态是否正常。
手势:(前)右臂平伸,五指张开并拢示意灯光闪动。
(后)左臂平伸,五指张开并拢示意灯光闪动。
5、危险报警闪光灯
目的:检查双闪灯功能状态是否正常。
手势:双臂平伸,双手五指张开并拢示意灯光闪动。
6、近光灯刹车灯
目的:检查(前)近光灯和(后)刹车灯功能及状态是否正常。
手势:双臂向前平伸指向车灯方向,手掌向下。
7、远光灯倒车灯
目的:检查(前)远光灯的功能状态和(后)倒车灯功能状态。
手势:双臂弯曲上举至头部,手心朝向面部。
四、安全注意事项
1、车身“三件套”:翼子板护垫、前格栅护垫。
2、车内“四件套”:座椅套、脚垫、方向盘套、挡杆套。
3、安放前后挡块。
4、降下驾驶位置车窗。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
# 通用版面风格 1 2 3 编写格式是否一致? 是否有可读性并易于维护? 文件是否过长? 检查项
ቤተ መጻሕፍቲ ባይዱ
通用代码编写规范 1 2 3 4 5 6 文件、变量以及方法命名是否统一且有意义? 是否用定义的常量代替实际的数据或字符串? 是否存在没有使用到的变量、代码或文件? 逻辑控制是否正确、简洁? 是否对异常进行了处理? 对外接口的输入输出参数是否进行了校验、记录?
通用注释规范 1 2 3 4 注释是否清晰、简洁,有助于他人对代码的理解? 注释是否解释了代码的目的,或总结了代码所要完成的工作? 注释是否与代码同步? 是否描述了文件目的、作者与修改记录?
是/否/不适用
是 是 是
是 是 否 是 是 是
否 是 是 是