团队作业（三）：确定分工

news/发布时间2024/8/24 9:30:59

一、代码规范和编码原则
明确代码编写的规范和原则是为了保证代码的正确性、稳定性、可读性，过于繁杂或故意展示技巧性的编码方式是无意义的，甚至对后续工作造成影响。

排版：

1.关键词和操作符之间加适当的空格。

2.相对独立的程序块与块之间加空行

3.较长的语句、表达式等要分成多行书写。

4.划分出的新行要进行适应的缩进，使排版整齐，语句可读。

5.长表达式要在低优先级操作符处划分新行，操作符放在新行之首。

6.循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分。

7.若函数或过程中的参数较长，则要进行适当的划分。

8.不允许把多个短语句写在一行中，即一行只写一条语句。

9.函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格。

10.C/C++语言是用大括号‘{ ’和‘ }’界定一段程序块的，编写程序块时‘{ ’和 ‘ }’应各独占一行并且位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、 switch、case语句中的程序都要采用如上的缩进方式。

注释：

1.注释是对代码的“提示”，而不是文档。程序中的注释不可喧宾夺主，注释太多会让人眼花缭乱。

2.如果代码本来就是清楚的，则不必加注释。

3.边写代码边注释，修改代码的同时要修改相应的注释，以保证注释与代码的一致性，不再有用的注释要删除。

4.当代码比较长，特别是有多重嵌套的时候，应当在段落的结束处加注释，这样便于阅读。

每一条宏定义的右边必须要有注释，说明其作用。

可读性：

1.避免使用不易理解的数字，用有意义的标识来替代。

2.不要使用难懂的技巧性很高的语句。

3.源程序中关系较为紧密的代码应尽可能相邻。

函数：

1.函数的规模尽量限制在200行以内。

2.一个函数最好仅完成一件功能。

3.为简单功能编写函数。

4.函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出。

5.尽量不要编写依赖于其他函数内部实现的函数。

6.避免设计多参数函数，不使用的参数从接口中去掉。

7.用注释详细说明每个参数的作用、取值范围及参数间的关系。

8.检查函数所有参数输入的有效性。

9.检查函数所有非参数输入的有效性，如数据文件、公共变量等。

10.函数名应准确描述函数的功能。

11.函数的返回值要清楚、明了，让使用者不容易忽视错误情况。

12.明确函数功能，精确（而不是近似）地实现函数设计。

13.减少函数本身或函数间的递归调用。

变量命名
1) 变量名的开头必须是字母或下划线，不能是数字。而以下划线开头的变量名是系统专用的。所以为了避免与系统定义的名字产生冲突，在编程的时候，除非要求这么定义，否则不使用下划线作为一个变量名的开头。
2) 变量名中的字母是区分大小写的。

3) 变量名绝对不可以是C语言关键字，如：else、break、return等。
4) 变量名中不能有空格。

以上变量命名规则是C语言语法规定的，必须遵守，不遵守就是错的。除此以外，还有一些约定成俗的变量命名规范。
1.不以单个字母作为变量名。变量名最好要有明确的含义，以提高代码的可读性
2.在实际编程中经常用英文单词或英文单词的缩写来作为变量名，而且缩写也有一定要规则：

通常较短的单词可通过去掉“元音”形成缩写，如 count 可以缩写成 cnt；

较长的单词可取单词中的几个字母形成缩写；

对于一些单词还有大家公认的缩写，比如：

temp 可缩写为 tmp; //temp是“临时”的意思

flag 可缩写为 flg; //flag是“标志位”的意思

statistic 可缩写为 stat; //statistic是“统计”的意思

increment 可缩写为 inc;

message 可缩写为 msg;
如果变量名由多个单词组成而且不用缩写，那么每个单词的首字母全部都要用大写，必要时可用下划线分隔。
二、架构设计

数据平台

无纸化电子公文传输系统以Lotus Notes构造整个系统的管理和传输的平台，公文数据集中存放在统一的Domino服务器中，发送方与接收方之间的公文传输，直接在这个Domino服务器上的不同数据库之间进行复制、拷贝，以确保公文流转的高效性和安全性。公文文件的制作、接收浏览，则通过客户端的终端软件实现 [1] 。

公章管理

电子公章既包含用以显示公章图形的可视信息，又包含用以数字电子签名的RSA私钥数据。电子公章的显示必须要有所属单位的对应RSA公钥数据，也只有正确对应的RSA公钥数据才可以显示出可视的公章图片信息·由于公章可视信息的法律严肃性特点，要求公章显示过程中，其图片信息不能被意外截取。为此无纸化电子公文传输系统对公章图片进行了矢量化处理，确保该图片信息只有在系统环境内部才有效。电子公章的使用同样离不开RSA的加解密操作。公章的主要数据信息通过硬件RSA加密卡存储，没有硬件加密卡设备，也就无法使用电子公章。这样同时可以方便用户以传统方式保管电子公章，如可以将加密卡保存在保险柜中。对于电子公章的使用，该系统提供了严密的日志跟踪措施，所有公章的制作、使用都有详细的日志记录。

红头制作

从外部导入的公文草件是不带红头和公章的。公文红头文件用于对指定文种的公文，套印对应的红头。为此可以通过公文红头管理模块，制作出一组不同的公文红头文件，并建立红头文件与文种的对应关系。红头文件的制作，可以直接以文本形式制作泞旨定好文本内容、字体、位置等有关信息)，也可以直接读人扫描件方式制作生成(为了打印输出的清晰度，扫描件必须以指定的500DPI分辨率获取)。制作公文时指定文种并导入公文草件。系统根据文种将对应的红头信息自动添加到公文文件的首页，完成套印红头。

公文制作

公文草件即用以制作公文文件的外部电子文档。是通过外部第三方编辑排版软件制作处理后的输出结果。公文草件所包含的文本内容一般不再需要重新排版，但草件不含公文的红头、公章等信息。公文草件可以是WORD输出的RTF文档，也可以是以本系统的电子公文虚拟打印输出的JWE图片文件。公文的制作就是引入外部的公文草件如RTF、JWE(图片文档)，按照草件所属的文种，自动套印相应的公文红头。当RFT格式的公文草件导人时，可以进行简单的二次公文编辑，可以自动校验特定的公文要素是否正确，如版心的设置是否正确、公文文号是否正确、联系人是否具备等等。当JWE(图片文档)格式的公文草件导入时，可进行整版位置调整等操作。当公文草件导入成功后系统需要对导人的数据，通过加密卡的私钥，以时间戳模式进行电子数字签名。经过套印红头、电子签名后的电子文件才真正成为电子公文文件。

公文分发

公文的分发也就是选择收文单位，获取收文单位的加密卡公钥，根据所得的对方公钥对发文进行RSA加密，最后将电子公文文件发送给指定收文单位。

公文接收

收文单位接收服务器上的公文，并转入自己的公文收件箱。为打开公文收件箱中的公文，要以本单位特定的加密卡私钥对收文进行解密，解密成功后，下载获取发文单位的加密卡公钥，以此对解密后的公文进行电子签名验证。通过电子签名验证后，可以确认所收公文来自发文单位，从而保证本地专用的公文，浏览器可解读和阅读收文。公文浏览器在首次阅读收文文件时，可以加盖本单位的收文签收章，这样打印输出的公文即带有本单位的公文签收章。