代码敲不队——Beta代码规范与计划
这个作业的属于哪个课程 | 2018软件工程2班 |
---|---|
这个作业的要求在哪里 | Beta冲刺 |
这个作业的目标 | 明确冲刺阶段的任务计划以及预期目标 |
团队成员 | 欧阳小云、赵贝贝、石云凤、谢菲菲、毛菁菁、邱晴 |
作业正文 | 见下文 |
一、代码规范
1.排版
1.程序块要采用缩进风格编写,缩进的空格数为4个。
2.相对独立的程序块之间、变量说明之后必须加空行。
3.不允许把多个短语句写在一行中,即一行只能写一条语句。
4.if、for、do、while、case、switch、default等语句自占一行,且if、for、do、while等语句的执行语句部分无论多少都要加大括号{ }。
6.对齐只使用空格键,不使用Tab键。
7.代码行之内应该留有适当的空格。
8.程序的分界符应各独占一行并且位于同一列,同时与引用它们的语句左对齐。if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。
9.进行非对等操作时,如果是关系密切的立即操作符(例如->),后面不应加空格。
10.类与方法体开始“{”与结束“}”必须自成一行。
2.注释
1.源文件头部应进行注释,列出:生成日期、作者、模块目的功能等。
2.函数头部应进行注释,列出:函数的目的/功能、输入参数、输出参数、返回值等等。
3.注释应该和代码同时更新,不再有用的注释要删除。
4.注释的内容要清楚、明了,不能有二义性。
5.避免在注释中使用非常用的缩写或者术语。
6.注释的主要目的应该是解释为什么这么做,而不是正在做什么。
7.避免非必要的注释。
8.注释应与其描述的代码相近,对代码的注释应放在其上方或右方(对单条语句的注释)相邻位置,不可放在下面。
9.注释不宜过多,也不能太少,源程序中有效注释量控制在20%~30%之间。
10.将注释和上面的代码用空行隔开。
11.注释与所描述内容进行同样的缩排。
3.标识符命名
1.命名尽量使用英文单词,求简单清楚,避免使用引起误解的词汇和模糊的缩写,使人产生误解。
2.命名规范必须与所使用的系统风格保持一致,并在同一项目中统一。
3.变量的命名使用驼峰命名法(例如:myFirstName)。
4.命名中若使用了特殊的约定或者缩写,则要有注释说明。
5.命名风格要始终保持一致,不可来回变化。
6.除非必要,不要用数字或较奇怪的字符来定义标识符。
7.类常量名称必须全部大写,多个单词用下划线分隔。
8.类名必须遵循大写开头的驼峰命名规范。
9.方法名必须符合小写开头的驼峰命名规范。
10.PHP开源框架中一个文件应该有一个类,且文件名必须与类名。
11.PHP开源框架中每个命名空间必须有对应的同名目录,并且必须区分大小写。
12.继承与实现接口extends和implements必须写在类名称的同一行。
13.PHP开源框架中true、false和null必须使用小写。
14.静态方法static必须声明在访问修饰符之后。
4.可读性
1.用括号明确表达式的操作顺序,避免使用默认优先级。
2.不要编写太复杂、多用途的复合表达式。
3.禁止使用难以理解,容易产生歧义的语句。
4.namespace或use声明后必须插入一个空白行。
5.类的属性和方法必须添加访问修饰符。
6.PHP脚本的编码必须以不带BOM的UTF-8编码。
7.PHP脚本的开始标签必须以<?php或<?=标签开始。
5.变量、结构
1.尽量少使用全局变量,尽量去掉没必要的公共变量。
2.仔细设计结构中元素的布局与排列顺序,使结构容易理解、节省占空间,并减少引起误用现象。
3.留心具体语言及编译器处理不同数据类型的原则及有关细节。
4.尽量减少没有必要的数据类型默认转换与强制转换。
6.函数、过程
1.编写可重入函数时,应注意局部变量的使用。
2.一个函数仅完成一件功能。
3.禁止编写依赖于其他函数内部实现的函数。
4.谨慎使用与程序运行的环境相关的系统函数。
5.检查函数所有参数与非参数的有效性。
6.函数的返回值要清楚、明了,让使睹不容易忽视错误情况。
7.可测性
1.使用断言来发现软件问题,提高代码可测性。
2.用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。
3.不能用断言来检查最终产品肯定会出现且必须处理的错误情况。
4.对较复杂的断言加上明确的注释。
5.用断言确认函数的参数。
6.用断言保证没有定义的特性或功能不被使用。
8.程序效率
1.在保证软件系统的正确性、稳定性、可读性及可测性的前提下,提高代码效率。
2.局部效率应为全局效率服务,不能因为提高局部效率而对全局效率造成影响。
3.循环体内工作量最小化。
4.避免循环体内含判断语句,应将循环语句置于判断语句的代码块之中。
5.在逻辑清楚且胚影响可读性的情况下,代码越少越好。
6.尽量使用标准库函数,不要“发明”已经存在的库函数。
7.要尽量重已有的代码,直接调已有的API。
9.质量保证
1.只引用属于自己的存储空间。
2.防止引用已经释放的内存空间。
3.防止内存操作越界。
4.要时刻注意易混淆的操作符。当编完程序后,应从头至尾检查一遍这些操作符,以防止拼写错误。
5.条件表达式要把常量写在前面。
6.有可能的话,if询尽量加上else分支,对没有else分支的语句要小心对待;switch语句必须有default分支。
7.不使用与硬件、操作系统、或编译器相关的语句,而使用建议的标准语句,以提搞软件的可移植性和可重用性。
8.时刻注意表达式是否会上溢、下溢。
9.通过代码走读及查仿式对代码进行检查。
10.打开编译器的所有告警开关对程序进行编译,并且要确认处理所有的编译告警。
11.如果可能,元测试要覆盖98%以上的代码,尽可能早地发现和解决问题。
10.代码编辑、编译、审查
1.测试部测试产品之前,应对代码进行抽查及评审。
2.通过代码走读及审查方式对代码进行检查。
3.要小心地使用编辑器提供的块拷贝功能编程。
4.合理地设计软件系统目录,方便开发人员使用。
5.某些语句经编译后产生告警,但如果你认为它是正确的,那么应通过某种手段去掉告警信息。
6.使用软件工具进行代码审查。
7.测试产品之前,应对代码进行抽查及评审。
8.同产品软件内,最好使用相同的编辑器,并使用相同的设置选项。
9.使用代码检查工具对源程序检查。
11.代码测试、维护
1.单元测试要求至少达到语句覆盖。
2.单元测试开始要跟踪每一条语句,并观察数据流及变量的变化。
3.清理、整理或优化后的代码要经过审查及测试。
4.代码版本升级要经过严格测试。
5.使用工具软件对代码版本进行维护。
6.发现错误立即修改,并且要记录下来。
7.关键的代码在汇编级跟踪。
8.仔细设计并分析测试用例,使测试用例覆盖尽可能多的情况,以提高测试用例的效率。
10.仔细测试代码处理数据、变量的边界情况。
11.测试时应设法使很少发生的事件经常发生。
12.宏
1.用宏定义表达式时,要使用完备的括号。
2.将宏所定义的多条表达式放在大括号中。
3.使用宏时,不允许参数发生变化。
二、任务计划以及预期目标
第一天 | 12.15 | 后端实现基础功能,前端根据后端增加的功能增加图标/入口 |
---|---|---|
第二天 | 12.16 | 后端实现基础功能,前端根据后端增加的功能增加图标/入口 |
第三天 | 12.17 | 后端实现基础功能,前端根据后端增加的功能增加图标/入口 |
第四天 | 12.18 | 后端实现基础功能,前端根据后端增加的功能增加图标/入口 |
第五天 | 12.19 | 对代码进行整合,完成阶段测试,对不足的地方加以改进 |
第六天 | 12.20 | 后端尝试增加新功能,前端配合增加、进行上线发布准备工作 |
第七天 | 12.21 | 后端尝试增加新功能,前端配合增加、进行上线发布准备工作 |
第八天 | 12.22 | 对发布后产生的问题进行修复,对不足的地方加以改进 |
第九天 | 12.23 | 对代码进行整合,完成阶段测试,对不足的地方加以改进 |
第十天 | 12.24 | 项目基本完成,进行收尾工作,对存在的问题进行总结 |