欢天喜地七仙女——Beta冲刺代码规范与计划
| 这个作业的要求在哪里 | 作业要求 |
|---|---|
| 团队名称 | 欢天喜地七仙女 |
| 团队成员 | 王玮晗、林鑫宇、 黄龙骏、陈少龙、何一山、崔亚明、陆桂莺 |
| 这个作业的目标 | 编辑Beta冲刺代码规范与计划博客 |
| 作业正文 | 如下 |
| 参考文献 | 见文末 |
一.代码规范
1.排版
1.程序块采用缩进分格编写，按tab缩进2.相对独立的程序块之间、变量说明之后必须加空行，如
//变量定义
var tmpTis = this.orderbyList[index].text + '排序 ';
//判断
if (this.orderbyList[index].orderbyicon) {
}
3.较长的语句分成多行书写，划分出的新行要进行适当缩进，使排版美观，如
var SQL_ADD_LOG
= "this is a long string-----------------------------";
4.循环、判断等语句若较长应进行适当划分，划分出的新行要进行适当缩进，使排版美观
5.若函数或过程中的参数过长进行适当划分，划分出的新行要进行适当缩进，使排版美观
6.一行只写一个语句
7.if、for、do、while、case、switch、default等语句独占一行，且if、for、do、while等语句执行部分需加{}，{}分别独占一行，如
for (var i = begin; i <= end; i++)
{
if(!(/^1(3|4|5|6|7|8|9)\d{9}$/.test(this.phoneNumber))
{
}
}
8.小组内使用统一的编码工具，所以对齐都使用tab键
9.=、+、-、*、/、%、&&、||、&、<<、>>、^前后加空格，如
var i = 0;
10.！、~、++、--、&（地址运算符）、->、.、前后不加空格，如
i++;
11.一行代码不超过80个字符
12.不同功能的语句块（包含注释）之间需空行
13.前端文件目录结构按照vue-cli通用的目录结构
14.每个.vue 文件最多包含一个<template>块，
每个.vue文件最多包含一个<script>块，一个 .vue 文件可以包含多个 <style> 标签
2.注释
1.非基础语句需添加注释，方便组员阅读2.函数头部进行注释，列出功能、参数、返回值、必要时列出调用关系，如
/**
* 登录功能实现
*/
doLogin(){
}
3.边写代码边注释，保证注释与代码一致
4.注释内容要避免歧义
5.注释中使用缩写需解释缩写
6.注释应在要解释的代码上方，与描述代码同缩进，如
//变量定义
var tmpTis = this.orderbyList[index].text + '排序 ';
7.变量命名不能充分自释义的需在变量后方加上注释,如
const alength;//数组a的长度
8.设置语言块的 lang 属性，方便其它组员阅读,如
<style>
/* write Sass! */
</style>
3.标识符命名
1.标识符命名要清晰、明了，有明确含义，不要使用缩写2.变量命名需有意义（局部循环遍量除外，如i）
4.可读性
1.不要使用默认的优先级，应用括号明确表示操作顺序2.变量、方法等命名应有意义
5.变量、结构
1.全局变量应该大写，如
var USER;
2.防止局部变量与公共变量同名
3.结构的功能要单一
4.注意数据类型的强制转换
6.函数、过程
1.明确函数功能2.接口函数参数的合法性检查与缺省由函数调用者负责
3.防止将函数的参数作为工作变量，防止改变参数内容
4.函数的规模尽量在200行以内
5.一个函数仅完成一个功能
6.尽量不要编写依赖于其它函数内部实现的函数
7.避免设计多参数函数，不使用的参数从接口中去掉
8.函数名应准确描述函数功能，使用动宾词组为函数命名
9.函数返回值要清楚明了
10.除注释外，函数内部不要出现不必要的代码，避免产生代码垃圾
11.减少函数本身或函数间的递归调用
7.可测性
1.在同一项目组或产品组内，调测打印出的信息串的格式要有统一的形式。信息串中至少要有所在模块名（或源文件名）及行号2.在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数，并且要有详细的说明
3.编程的同时要为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中的安装与拆卸（通过调测开关）
4.编写防错程序
5.在编写代码前，应预先设计好程序调试与测试的方法和手段
6.在正式的产品中应把调测代码去掉
8.程序效率
1.编码时要经常注意代码的效率2.在保证软件系统的正确性、稳定性、可读性及可测性前提下，提高代码效率
3.循环体内工作量最小化
4.仔细分析，进行优化，丢弃不必要代码
5.尽量减少循环嵌套层次
6.不要一味追求紧凑的代码
9.质量保证
1.代码质量保证正确性、稳定性、安全性、可测试性、可读性、效率2.只引用属于自己的空间
3.防止引用已经释放的内存空间
4.及时释放相应内存空间
5.防止内存操作越界
6.认真处理程序所能遇到的各种出错情况
7.系统运行之初，要初始化一关变量及运行环境，防止未经初始化的变量被引用
8.系统运行之初，要对加载到系统中的数据进行一致性检查
9.不能随意改变与其他模块的接口
10.充分了解系统的接口之后，再使用系统提供的功能
10.代码编辑、编译、审查
1.通过代码走读及审查方式对代码进行检查2.测试产品之前，应对代码进行抽查
3.编写代码时要注意随时保存，并定期备份，防止由于断电，硬盘损坏等原因造成代码丢失
4.使用相同的编译器，使用相同的配置选项
5.合理地设计软件系统目录，方便开发人员使用
6.使用软件工具（如logiscope）进行代码审查。
11.代码测试、维护
1.单元测试要求至少达到语句覆盖2.单元测试开始要跟踪每一条语句，并观察数据流及变量变化
3.清理、整理或优化后的代码要经过审查及测试
4.代码版本升级要经过严格测试
5.使用软件工具对代码进行维护
6.发现错误立即修改
7.仔细分析设计测试用例，尽可能覆盖更多的情况
8.仔细处理代码的边界情况
9.在编码阶段就要进行代码的单元测试
12.commit message规范
1.每次提交代码，都要写 Commit message2.格式：
-
type: subject-
type
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
-
subject
简短描述commit内容
-
-
例如：
git commit -m'docs:代码规范增加commit message规范'
二.计划
| 规划天数 | 任务进度及安排 |
|---|---|
| 第一天 | 规范代码及分配任务，明确队员负责的内容 |
| 第二天 | 修改页面中不够美观的页面，进行相互交流 |
| 第三天 | 为数据库插入能够供用户使用的数据 |
| 第四天 | 增加帖子的修改和草稿箱功能，后端添加相应接口，前端完善相应界面，讨论还需要加的功能 |
| 第五天 | 增加搜索功能，后端添加相应接口，前端完善相应界面，讨论还需要加的功能 |
| 第六天 | 综合讨论内容，再添加一个必要功能，后端添加相应接口，前端完善相应界面 |
| 第七天 | 整合代码，进行测试 |
| 第八天 | 找到用户使用APP，收集建议和问题 |
| 第九天 | 根据使用情况对代码进行相应修改 |
| 第十天 | 最终测试，交付，ppt制作 |
