Alpha冲刺——代码规范与计划
| 这个作业属于哪个课程 | 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：去除代码运行的随机性（如去掉无用的数据、代码及尽可能防止并注意函数中的“内部寄存器”等），让函数运行的结果可预测，并使出现的错误可再现。
| “冲刺计划” |
| “参考文献” |
