七_魔仙堡——Beta冲刺代码规范与计划

这个作业属于哪个课程	18级软件工程和UML
这个作业要求在哪里	作业要求
这个作业的目标	提交一份关于团队的代码规范以及本次冲刺计划的随笔，计划要求包括冲刺阶段的任务计划以及预期目标
团队成员	王晶晶，陈洁，陈伟钧，蒲子怡，吴越，林雪凡，应海鹭
其他参考文献	如下

“代码规范”

????1.排版

1.程序块采用缩进编写风格，缩进的空格数为4个。

2.大括号使用约定，若大括号内为空。简洁写成{}即可。否则：除左大括号左边不需要换行外，左大括号右边、右大括号左右两边均需要换行。
3.代码之间应该留适当的空格。如：
(1)数学运算符左右两边均需要空格。
(2)！、~、++、--、&（地址运算符）、->、.、前后不加空格。
(3)if/for/while/switch/do等保留字与括号之间都必须加空格。
4.一行只写一个语句。
5.方法调用时，需要多个换行时，在点号或逗号前换行。
6.if…else嵌套语句不得超过三层。采用取反、短路结束逻辑。
7.一行代码小于80个字符。大于80个字符，分成多行书写。
8.if、for、do、 while、 case、switch、default等语句自占一行，且if、for、do、while等语句的执行语句部分无论多少都要加括号{}。

????2.注释

1.方法内部单行注释，在备注语句上方另起一行，使用//注释。方法内部多行注释使用/* */注释，注意对齐。方法若多层调用且相当复杂，斟酌加上实际逻辑对应的文字说明。
2.所有的枚举字段、常量字段均需要注释说明。说明具体用途。
3.谨慎注释掉代码。做详细说明、如注释原因、后续是否会恢复。若永不再用，则直接删除。
4.边写代码边注释，修改代码的同时修改注释，保证注释与代码一致。
5.避免在注释中使用缩写，特别是不常用的缩写和术语。
6.注释的内容要清楚、明了，含义准确。
7.函数头部进行注释，列出功能、参数、返回值、必要时列出调用关系（函数、表）等。
8.注释与所描述的内容进行同样的缩排。
9.避免在一行或表达式的中间插入注释。
10.对于所有有物理含义的变量、常量，如果其命名不是充分自注释的，在声明时都必须加以注释，说明其物理含义。

????3.标识符命名

1.标识符命名要清晰、明了，有明确含义，命名尽量使用英文单词，力求简单清楚，避免使用引起误解的词汇和模糊的缩写，使人产生误解。
2.不用数字或较奇怪的字符来定义标识符。
3.对于变量命名，禁止取单个字符(如i、j、k...)，建议除了要有具体含义外，还能表明其变量类型、数据类型等，但i、j、k作局部循环变量是允许的。

????4.可读性

1.注意运算符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。
2.不要使用难懂的技巧性很高的语句，除非很有必要时。
3.涉及物理状态或者含有物理意义的常量，避免直接使用数字，必须用有意义的枚举或常量来代替。
4.不要编写太复杂、多用途的复合表达式。
5.禁止使用难以理解,容易产生歧义的语句。

????5.变量，结构

• 变量：
  1）常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
  2）为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词
  组合来表达其意。
  3）不要使用一个常量类维护所有常量，要按常量功能进行归类，分开维护。

• 结构：
  1、大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果
  是非空代码块则：
  1） 左大括号前不换行。
  2） 左大括号后换行。
  3） 右大括号前换行。
  4） 右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行。
  2、不同逻辑、不同语义、不同业务的代码之间插入一个空行分隔开来以提升可读性。

????6.函数、过程

1.短小
2. 只做一件事
3.使用描述性的名称
4.无副作用
5.每个函数一个抽象层级
6.函数参数
7.使用异常，不要返回错误码
8.别重复自己
9.尽量少用switch语句
10.反复打磨、分解函数、修改名称、消除重复、测试。让函数更加短小，职责更加单一，命名更加合理。

• 耦合性：
  1、尽量通过参数接收输入，以及通过return产生输出以保证函数的独立性
  2、尽量减少使用全局变量进行函数间通信
  3、不要在函数中改变可变类型的参数
  4、避免直接改变定义在另一个模块中的变量

• 聚合性：
  1、每个函数目标是唯一的
  2、每隔函数尽量简单

????7.可测性

1.单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的，执
行过程必须完全自动化才有意义。
2.单元测试是可以重复执行的，不能受到外界环境的影响
3.核心业务、核心应用、核心模块的增量代码确保单元测试通过。
4.对于数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的，
或者直接操作数据库把数据插入进去，请使用程序插入或者导入数据的方式来准备数据。
5.对于不可测的代码建议做必要的重构，使代码变得可测，避免为了达到测试要求而
书写不规范测试代码。
6.单元测试作为一种质量保障手段，不建议项目发布后补充单元测试用例，建议在项
目提测前完成单元测试。

????8.程序效率

1、在编写程序前，尽可能化简有关的算术表达式和逻辑表达式。
2、仔细检查算法中的嵌套循环，尽可能将某些语句或表达式移到循环外面。
3、尽量避免使用多维数组。
4、尽量避免使用指针和复杂表达式。
5、采用快速的算术运算。
6、不要混淆数据类型，避免在表达式中出现类型混杂。
7、尽量采用整数算术表达式和布尔表达式。
8、选用等效的高效率算法。

????9.质量保证

1.代码质量保证正确性、稳定性、安全性、可测试性、可读性、效率
2.只引用属于自己的空间
3.防止引用已经释放的内存空间
4.及时释放相应内存空间
5.防止内存操作越界
6.认真处理程序所能遇到的各种出错情况
7.系统运行之初，要初始化一关变量及运行环境，防止未经初始化的变量被引用
8.系统运行之初，要对加载到系统中的数据进行一致性检查
9.不能随意改变与其他模块的接口
10.充分了解系统的接口之后，再使用系统提供的功能

????10.代码编辑、编译、审查

1：打开编译器的所有告警开关对程序进行编译。
2：在产品软件（项目组）中，要统一编译开关选项。
3：通过代码走读及审查方式对代码进行检查。
4：测试部测试产品之前，应对代码进行抽查及评审。
5：编写代码时要注意随时保存，并定期备份，防止由于断电、硬盘损坏等原因造成代码丢失。
6：同产品软件（项目组）内，最好使用相同的编辑器，并使用相同的设置选项。
7：要小心地使用编辑器提供的块拷贝功能编程。
8：合理地设计软件系统目录，方便开发人员使用。
9：某些语句经编译后产生告警，但如果你认为它是正确的，那么应通过某种手段去掉告警信息。
10：使用代码检查工具（如C语言用PC-Lint）对源程序检查。
11：使用软件工具（如 LogiSCOPE）进行代码审查。

????11.代码测试、维护

1：单元测试要求至少达到语句覆盖。
2：单元测试开始要跟踪每一条语句，并观察数据流及变量的变化。
3：清理、整理或优化后的代码要经过审查及测试。
4：代码版本升级要经过严格测试。
5：使用工具软件对代码版本进行维护。
6：正式版本上软件的任何修改都应有详细的文档记录。
7：发现错误立即修改，并且要记录下来。
8：关键的代码在汇编级跟踪。
9：仔细设计并分析测试用例，使测试用例覆盖尽可能多的情况，以提高测试用例的效率。
10：尽可能模拟出程序的各种出错情况，对出错处理代码进行充分的测试。
11：仔细测试代码处理数据、变量的边界情况。
12：保留测试信息，以便分析、总结经验及进行更充分的测试。
13：不应通过“试”来解决问题，应寻找问题的根本原因。
14：对自动消失的错误进行分析，搞清楚错误是如何消失的。
15：修改错误不仅要治表，更要治本。
16：测试时应设法使很少发生的事件经常发生。
17：明确模块或函数处理哪些事件，并使它们经常发生。
18： 坚持在编码阶段就对代码进行彻底的单元测试，不要等以后的测试工作来发现问题。
19：去除代码运行的随机性（如去掉无用的数据、代码及尽可能防止并注意函数中的“内部寄存器”等），让函数运行的结果可预测，并使出现的错误可再现。

????白话总结

• 首先是文件名的命名。在Alpha冲刺阶段，我们遇到的一大问题就是代码的整合、共享与调配。最后我们选择了最简单的方法以数字进行编号（即第一版用01，第二版用02，如此以往）。
• 其次是数据表结构的命名。数据表的命名的逻辑性也是一大难事，最后采取：类_成员 进行了命名。
• 再者是代码格式，使用HX进行了一键排版，一目了然，心情舒畅。
• 最后是前端代码的统筹集合。将前端代码整合成头文件进行引用可以是减少大块代码，但这也不是一件易事。

“冲刺计划”

有了Alpha冲刺的前车之鉴，我们对Beta的规划做出了一些调整，将前端整体往后挪以避免代码重复与冗余

“参考文献”

腾讯编码规范
华为编码规范