七_魔仙堡——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的规划做出了一些调整，将前端整体往后挪以避免代码重复与冗余

“参考文献”

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