.Matrix-Beta代码规范与计划随笔

这个作业属于哪个课程	班级链接
这个作业要求在哪里	Beta冲刺
这个作业的目标	完成Beta冲刺的任务计划以及对代码规范进行迭代更新
作业正文	如下
其他参考文献	华为内部代码规范

一、代码规范

1、排版

1.1 程序块要采用缩进风格写，缩进时使用tab

1.2 相对独立的程序块之间，变量说明之后必须加空行

1.3 较长的语句(>80字符)要分成多行书写，长表达式要在低级先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，语句可读。

1.4 函数或过程中的参数较长，要进行适当的划分

1.5 对齐只是用空格键，不使用tab键

1.6 if,for,do,while,case,switch,default等语句自占一行,且if，for，do，while语句的执行语句无论多少都要加{}

1.7 逗号、分号只在后面加空格，比较操作符("=","+=","+","%","&&","&","<<","^")等要在前后加空格。

2.注释

2.1 注释在源程序的占比有20%

2.2 说明性文件必须要注释

2.3 代码和注释同步更新，并且注释内容要避免歧义

2.4 在注释中不使用缩写

2.5 注释应该放在代码的上方(空行)或者右方，切记不可放在下面

3.标识符命名

3.1 标识符的命名要清晰明了，使用完整单词或者通俗易懂的缩写

3.2 不可使用数字或者奇怪的字符定义标识符

3.3 对于变量命名，禁止取单个字符（如i,j,k...）

3.4 在同一软件产品内，应该规划接口部分标识符(变量、结构、函数及常量)

4.可读性

4.1 注意运算符的优先级，避免使用默认优先级

4.2 避免使用不易理解的数字，用有意义的标识来替代

4.3 源程序中较为紧密的代码应尽可能相邻

5.变量、结构

5.1 去掉没必要的公共变量

5.2 防止局部变量与公共变量同名

5.3 结构功能要单一

5.4 使用严格形式定义的、可移植的数据类型，尽量不要使用与具体硬件或软件环境关系的变量。

6.函数、过程

6.1 明确函数功能，精确地实现函数设计

6.2 函数的规模尽量限制在200行以内

6.3 一个函数仅完成一个功能

6.4 避免设计多参数函数，不使用的参输从接口中删去

6.4 不使用无意义或者含义不清的动词给函数命名

6.5 函数内部不要出现非必要的代码，避免生成代码垃圾

6.6 减少函数本身或函数间的递归调用

6.7 提供返回值的函数，在引用时最好使用返回值

7.可测性

7.1 在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数，并且要有详细的说明。

7.2 在进行集成测试联调之前，要构建好测试环境、测试项目及测试用例、同时仔细分析并优化测试用例，以提高测试效率。

7.3 用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。

7.4 编写防错程序，然后再处理错误之后可用断言宣布发生错误。

7.5 对较为复杂的断言加上明确的注释

7.6 用断言保证没有定义的特性或功能不被使用

8.程序效率

8.1 编程时要注意代码的效率

8.2 局部效率应为全局效率服务，不能因为提高局部效率而对全局效率造成影响

8.3 仔细分析有关算法，并进行优化

8.4 在多重循环中，应将最忙的循环放在最内层

9.质量保证

9.1 只引用自己的存贮空间，并且防止引用已经释放的内存空间

9.2 过程/函数中申请的文件句柄，在过程/函数退出之前要关闭

9.3 系统运行之初，要对加载到系统中的数据进行一致性检查

9.4 不可随意改变与其他模块的接口

10.代码编辑、编译、审核

10.1 打开编译器的所有警告开关对程序进行编译

10.2 编写代码时要注意随时保存，并定期备份，防止由于断电、硬盘损坏等原因造成代码丢失

10.3 合理地设计软件系统目录，方便开发人员使用

10.4 使用代码检查工具对源程序检查，使用软件工具进行代码审查

11.代码测试、维护

11.1 单元测试要求至少达到语句覆盖

11.2 清理、整理或优化后的代码要经过审查及测试

11.3 代码版本升级要经过严格测试

11.4 使用软件工具对代码经过严格测试

11.5 仔细分析设计测试用例、尽可能覆盖更多的情况

11.6 仔细处理代码的边界情况

11.7 在编码阶段就要开始对代码进行单元测试

12.宏

12.1 用宏定义表达式时，要使用完备的括号

12.2 将宏定义的多条表达式放在大括号中

12.3 使用宏时，不允许参数发生变化

12.commit message规范

13.1每次提交代码，都要写commit message

13.2格式：

• type
  • feat:新功能(feature)
  • docs:文档(documentation)
  • style:格式（不影响代码运行的变动)
  • refactor:重构（即不是新增功能，也不是修改bug的代码变动)
  • test:增加测试
  • chore:构建过程或辅助工具的变动
• subject
  • 简短描述commit内容
• 例如：
  • git commit -m 'docs:代码规范增加commit message规范
  • 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
  • 第一个字母小写
  • 结尾不加句号（.）

二、冲刺阶段的任务计划

规划日期	任务进度及安排
第一天	讨论凡事预则立，阅读更新的代码规范，完成总体任务规划
第二天	后端修改登陆注册bug代码，前端修改登录注册bug，完成登陆注册功能
第三天	后端修改忘记密码，更改密码等功能，前端修改相应代码bug，实现用户忘记密码，更改密码功能
第四天	后端更改重命名、新建文件夹等功能bug代码，前端修改相应bug，实现对文件进行相应操作功能
第五天	前后端进行Beta冲刺第一次衔接，总结问题并且进行修改
第六天	后端更改上传下载功能代码，前端进行相应bug代码修改，实现上传下载功能
第七天	进行复盘，总结问题集中修改代码
第八天	完成前后端界面优化
第九天	完成用户使用调查报告
第十天	测试，完成本阶段任务

三、预期目标

• 完成上传下载核心功能，文件的重命名、删除等操作的第一版'四维口袋'APP