The second week --DIG team blog
Revise and improve the requirements specification filed last week
Changes in the population served
Considering the confidential nature of our school unique, modify the application by a panel discussion crowd, turned to specific groups in specific local network from the public, such as: the military, the secret base, such as mountain
Modify scenarios
- User scenario A: Xiaowei and small Zou soldiers in a special training base, time-critical, as soon as possible to understand all the dishes, a la carte, use APP.
- User scenario B: Park saw a small cafeteria food, that is not good, choose to jump to the US Mission in the APP, the interface to enter the US group, performed fancies.
Cancel payment interface
After the actual investigation, we learned that want to connect micro-channel or pay-interfaces to our APP, not actual. Micro-channel and Alipay request for additional user licenses only have three years of operation by, had to give up
Details of the flowchart is modified
Code specification and coding principles
Program style:
- Strictly hierarchical organization using the ladder program code
- Each level of indentation is 4 spaces brackets on the next line. Match the requirements of braces in the same column, following the line of the grid requires re-indent 4
- Tip Tip string string position information in the program given the need, in order to support the development of multiple languages, in addition to some temporary debugging information, and all other message must be defined in the resource.
- Definition of variables, as far as possible at the beginning of a function of position.
Naming Rules
- Naming variable name;
- Analysis: variable name follows the naming user-defined identifier naming rules
- It can only consist of letters, numbers, underscores;
- The first character must be in English letters;
- An effective length of 255 characters;
- Not contain punctuation and type specifier%, &, #, @, $!;
- Keywords can not be a system such as else
Note
- Notes should be simple and straightforward.
- Side comments while writing the code, modify the code at the same time modify the notes, in order to ensure consistency with the annotated code.
- Where necessary annotations, to moderate volume. The content of comments to make it clear, clear, precise meaning, to prevent ambiguity comment.
- Notes held adjacent thereto description code, i.e., annotations proximity principle.
- Note that the code should be placed adjacent to the top position, not at the bottom.
- Note should be placed on the data structure thereabove adjacent positions, is not placed below; annotations to the structure of each field should be placed to the right of this domain;
- Note the same structure to align a different domain.
- Variables, constants comments should be placed adjacent to its upper position or to the right.
- Global variables have more detailed comments, including its function, the range, which indicates that it accesses a function or procedure and precautions when accessed.
- 在每个源文件的头部要有必要的注释信息，包括：文件名；版本号；作者；生成日期；
- 模块功能描述（如功能、主要算法、内部各部分之间的关系、该文件与其它文件关系等）；
- 主要函数或过程清单及本文件历史修改记录等。
- 在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能描述；
- 输入，输出及返回值说明；调用关系及被调用关系说明等。
可读性
- 避免使用不易理解的数字，用有意义的标识来替代。
- 不要使用难懂的技巧性很高的语句。
- 源程序中关系较为紧密的代码应尽可能相邻。
函数过程
- 函数的规模尽量限制在200行以内。
- 一个函数最好仅完成一件功能。
- 为简单功能编写函数。
- 函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出。
- 尽量不要编写依赖于其他函数内部实现的函数。
- 避免设计多参数函数，不使用的参数从接口中去掉。
- 用注释详细说明每个参数的作用、取值范围及参数间的关系。
- 检查函数所有参数输入的有效性。
- 检查函数所有非参数输入的有效性，如数据文件、公共变量等。
- 函数名应准确描述函数的功能。
- 避免使用无意义或含义不清的动词为函数命名
- 函数的返回值要清楚、明了，让使用者不容易忽视错误情况。
- 明确函数功能，精确（而不是近似）地实现函数设计。
- 减少函数本身或函数间的递归调用。
- 编写 可重入函数时，若使用全局变量，则应通过关中断、信号量（即P、V操作）等手段对其加以保护。
变量编辑
- 去掉没必要的公共变量。
- 构造仅有一个模块或函数可以修改、创建，而其余有关模块或函数只访问的公共变量，防止多个不同模块或函数都可以修改、创建同一公共变量的现象。
- 仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。
- 明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改及创建等。
- 当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界等现象发生。
- 防止局部变量与公共变量同名。
- 仔细设计结构中元素的布局与排列顺序，使结构容易理解、节省占用空间，并减 少引起误用现象。
- 结构的设计要尽量考虑 向前兼容和以后的版本升级，并为某些未来可能的应用保留余地（如预留一些空间等）。
- 留心具体语言及编译器处理不同数据类型的原则及有关细节。
- 严禁使用未经初始化的变量。声明变量的同时对变量进行初始化。
- 编程时，要注意数据类型的 强制转换。
代码编译
- 编写代码时要注意随时保存，并定期备份，防止由于断电、硬盘损坏等原因造成代码丢失。
- 同一项目组内，最好使用相同的编辑器，并使用相同的设置选项。
- 合理地设计软件系统目录，方便开发人员使用。
- 打开编译器的所有告警开关对程序进行编译。
- 在同一项目组或产品组中，要统一编译开关选项.
- 使用工具软件对代码版本进行维护。