beta冲刺————代码规范与计划

这个作业属于哪个课程	https://edu.cnblogs.com/campus/fzzcxy/2018SE1
这个作业要求在哪里	https://edu.cnblogs.com/campus/fzzcxy/2018SE1/homework/11616
这个作业的目标	beta冲刺代码规范与计划
作业正文	如下
其他参考文献	无

一、代码规范

·语句书写：

1、若函数或过程中的参数较长，则要进行适当的划分。
2、对齐只使用空格键，不使用TAB键。
3、在所有文件中的代码要采用缩进风格，并且左右括号要位置对应。
4、在js、json、wxss文件中，左括号(如 “{、[” 等)要在代码后方，右括号(如 “}、]” 等)要与代码同缩进
5、在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或者前后要加空格；进行非对等操作时，如果是关系密切的立即操作符（如－>），后不应加空格。

·注释：

1、一般情况下，源程序有效注释量必须在20％以上。
2、边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。
3、注释的内容要清楚、明了，含义准确，防止注释二义性。
4、避免在注释中使用缩写，特别是非常用缩写。
5、注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面，如放于上方则需与其上面的代码用空行隔开。
6、数据结构声明(包括数组、结构、类、枚举等)，如果其命名不是充分自注释的，必须加以注释。对数据结构的注释应放在其上方相邻位置，不可放在下面；对结构中的每个域的注释放在此域的右方。
7、全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。
8、注释与所描述内容进行同样的缩排。
9、对变量的定义和分支语句（条件分支、循环语句等）必须编写注释。
10、避免在一行代码或表达式的中间插入注释。
11、在代码的功能、意图层次上进行注释，提供有用、额外的信息。
12、注释应考虑程序易读及外观排版的因素，使用的语言若是中、英兼有的，建议多使用中文，除非能用非常流利准确的英文表达。

·标识符命名：

1、标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。
2、命名中若使用特殊约定或缩写，则要有注释说明。
3、自己特有的命名风格，要自始至终保持一致，不可来回变化。
4、对于变量命名，禁止取单个字符（如i、j、k...），建议除了要有具体含义外，还能表明其变量类型、数据类型等，但i、j、k作局部循环变量是允许的。
5、命名规范必须与所使用的系统风格保持一致，并在同一项目中统一，比如采用UNIX的全小写加下划线的风格或大小写混排的方式，不要使用大小写与下划线混排的方式，用作特殊标识如标识成员变量或全局变量的m_和g_，其后加上大小写混排的方式是允许的。
6、除非必要，不要用数字或较奇怪的字符来定义标识符。
7、用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。
8、除了编译开关/头文件等特殊应用，应避免使用_EXAMPLE_TEST_之类以下划线开始和结尾的定义。

·可读性：

1、注意运算符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。
2、源程序中关系较为紧密的代码应尽可能相邻。
3、不要使用难懂的技巧性很高的语句，除非很有必要时。

·变量、结构：

1、去掉没必要的公共变量。
2、明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改及创建等。
3、当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界等现象发生。
4、防止局部变量与公共变量同名。
5、严禁使用未经初始化的变量作为右值。
6、使用严格形式定义的、可移植的数据类型，尽量不要使用与具体硬件或软件环境关系密切的变量。
7、结构的功能要单一，是针对一种事务的抽象。
8、不要设计面面俱到、非常灵活的数据结构。
9、不同结构间的关系不要过于复杂。
10、结构中元素的个数应适中。若结构中元素个数过多可考虑依据某种原则把元素组成不同的子结构，以减少原结构中元素的个数。
11、仔细设计结构中元素的布局与排列顺序，使结构容易理解、节省占用空间，并减少引起误用现象。
12、结构的设计要尽量考虑向前兼容和以后的版本升级，并为某些未来可能的应用保留余地（如预留一些空间等）。
13、对自定义数据类型进行恰当命名，使它成为自描述性的，以提高代码可读性。注意其命名方式在同一产品中的统一。

·函数、过程：

1、对所调用函数的错误返回码要仔细、全面地处理。
2、在同一项目组应明确规定对接口函数参数的合法性检查应由函数的调用者负责还是由接口函数本身负责，缺省是由函数调用者负责。
3、避免设计多参数函数，不使用的参数从接口中去掉。
4、尽量不要编写依赖于其他函数内部实现的函数。
5、函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出。
6、检查函数所有参数输入的有效性。
7、检查函数所有非参数输入的有效性，如数据文件、公共变量等。
8、函数名应准确描述函数的功能。
9、函数的返回值要清楚、明了，让使用者不容易忽视错误情况。
10、在调用函数填写参数时，应尽量减少没有必要的默认数据类型转换或强制数据类型转换。
11、避免函数中不必要语句，防止程序中的垃圾代码。
12、防止把没有关联的语句放到一个函数中。
13、减少函数本身或函数间的递归调用。
14、对于提供了返回值的函数，在引用时最好使用其返回值。

·7 可测性：

1、在同一项目组或产品组内，调测打印出的信息串的格式要有统一的形式。信息串中至少要有所在模块名（或源文件名）及行号。
2、编程的同时要为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中的安装与拆卸（通过调测开关）。
3、使用断言来发现软件问题，提高代码可测性。
4、用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。
5、不能用断言来检查最终产品肯定会出现且必须处理的错误情况。
6、对较复杂的断言加上明确的注释。
7、用断言确认函数的参数。
8、用断言保证没有定义的特性或功能不被使用。
9、正式软件产品中应把断言及其它调测代码去掉（即把有关的调测开关关掉）。
10、编写防错程序，然后在处理错误之后可用断言宣布发生错误。

·程序效率:

1、编程时要经常注意代码的效率。
2、在保证软件系统的正确性、稳定性、可读性及可测性的前提下，提高代码效率。
3、局部效率应为全局效率服务，不能因为提高局部效率而对全局效率造成影响。
4、通过对系统数据结构的划分与组织的改进，以及对程序算法的优化来提高空间效率。
5、仔细分析有关算法，并进行优化。
6、对模块中函数的划分及组织方式进行分析、优化，改进模块中函数的组织结构，提高程序效率。
7、不应花过多的时间拼命地提高调用不很频繁的函数代码效率。
8、在保证程序质量的前提下，通过压缩代码量、去掉不必要代码以及减少不必要的局部和全局变量，来提高空间效率。
9、在多重循环中，应将最忙的循环放在最内层。
10、避免循环体内含判断语句，应将循环语句置于判断语句的代码块之中
11、尽量用乘法或其它方法代替除法，特别是浮点运算中的除法。
12、不要一味追求紧凑的代码。

·质量保证：

1、在软件设计过程中构筑软件质量。
2、代码质量保证优先原则。
3、防止引用已经释放的内存空间。
4、防止内存操作越界。
5、认真处理程序所能遇到的各种出错情况。
6、系统运行之初，要对加载到系统中的数据进行一致性检查。
7、严禁随意更改其它模块或系统的有关设置和配置。
8、充分了解系统的接口之后，再使用系统提供的功能。
9、不能随意改变与其它模块的接口。
10、要时刻注意易混淆的操作符。当编完程序后，应从头至尾检查一遍这些操作符，以防止拼写错误。
11、使用变量时要注意其边界值的情况。

·代码编辑、编译、审查：

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

·代码测试、维护：

1、单元测试要求至少达到语句覆盖。
2、单元测试开始要跟踪每一条语句，并观察数据流及变量的变化。
3、清理、整理或优化后的代码要经过审查及测试。
4、发现错误立即修改，并且要记录下来。
5、正式版本上软件的任何修改都应有详细的文档记录。
6、对自动消失的错误进行分析，搞清楚错误是如何消失的。
7、不应通过“试”来解决问题，应寻找问题的根本原因。
8、坚持在编码阶段就对代码进行彻底的单元测试，不要等以后的测试工作来发现问题。
9、去除代码运行的随机性（如去掉无用的数据、代码及尽可能防止并注意函数中的“内部寄存器”等），让函数运行的结果可预测，并使出现的错误可再现。

二.冲刺计划

时间	计划内容
12月15	分配beta冲刺任务
12月16	完成部分附加页面的前端样式
12月17	完成alpha未完成的部分功能
12月18	新增相关合理功能
12月19	完善前端功能
12月20	完成后端代码
12月21	测试代码
12月22	调研用户体验报告
12月23	拍摄vlog
12月24	汇总beta冲刺