软件工程——团队作业3
一、团队编码规程
>代码规范与编码规则
我们代码风格的原则是:简明，易读，无二义性。
一．代码规范：
1. 文件之中不得存在无规则的空行，比如说连续十个空行。一般来讲函数与函数之间 的空行为2-3行。
2. 在函数体内部，在逻辑上独立的两个函数块可适当空行，一般为1-2行。
3. 尽量用公共过程或子程序去代替重复的功能代码段。
4. 使用括号清晰地表达算术表达式和逻辑表达式的运算顺序。如将 x=ab/cd 写 成 x=(ab/c)d可避免阅读者误解为x=(ab)/(cd)。
5. 避免采用过于复杂的条件测试。
6. 避免过多的循环嵌套和条件嵌套。
7. 一个函数不要超过200行。一个文件应避免超过2000行。
8. 避免采用多赋值语句，如x = y = z;。
9. 缩进：我们不采用TAB键，而是手动空格键输入
虽然tab键一般为4个空格键，但在很多的编辑器中都可以拓展tab为多个空格键。不采用tab键的理由是不同情况可能显示不同的长度，影响阅读体验。
10.行宽：行宽必须限制，但是以前有些文档规定的80字符行宽太小了（以前的计算机/打字机显示行宽为80字符），我们在这里设置为100字符。
11.括号：在复杂的条件表达式中，用括号清楚地表示逻辑优先级。使读者够快清楚地看出表达式的运算顺序。
12.断行与空白行的{}行：每个“{”和“}”都独占一行。例如：
if ( condition)
{
DoSomething();
}
else
{
DoSomethingElse();
}
13. 分行：多条语句不能放在同一行。
14.命名：采用驼峰式命名法，又叫小驼峰式命名法。
第一个单词首字母小写，后面其他单词首字母大写。
15.下划线问题：下划线用来分隔变量名字中的作用域标注和变量的语义，一个类型的成员变量通常用m_来表示。
16.大小写问题：
1）所有的类型/类/函数名都用Pascal形式，所有的变量都用Camel形式。
2）类/类型/变量：名词或组合名词，如Member、ProductInfo等。
3）函数则用动词或动宾组合词来表示，如get/set; RenderPage()
17.注释：
对于函数，应该从“功能”“参数”“返回值”“主要思路”“调用方法”“日期”等6个方面进行如下注释：
//程序开始
//=//
//功能
//参数
//入口
//出口
//返回
//==//函数名
注释（包括所有源代码）应只用ASCII字符，不要用中文或其他特殊字符，它们会极大地影响程序的可移植性
二．编码原则
1.错误处理：
80%的程序代码，都是对各种已经发生和可能发生的错误的处理。
如果错误会发生，那就让程序死的地方离错误产生的地方越近越好。
1）参数处理：在DeBug版本中，所有的参数都要验证其正确性。在正式版本中，从外部（用户或别的模块）传递过来的参数要验证其正确性 。
2）断言：当你觉得某事肯定如何，你可以用断言。
Assert (p != NULL);
然后可以直接使用变量p;
如果你认为某事可能会发生，这时就要用错误处理。
2.处理C++中的类：
1）类：a.使用类来封装面向对象的概念和多态
b.避免传递类型实体的值，应该用指针传递
c.对于有显式的构造和析构函数，不要建立全局的实体，因为你不 知道它们在何时创建和消除
d.只有在必要的时候，才使用“类”
2)公共/保护/私有成员Public、Private和Protected
按照这样的次序来说明类中的成员：public、protected、private
3.代码复审：步骤：
复审前，代码必须成功地编译，在所有要求的平台上，同时要编译DeBug| Retail版本。编译要用团队规定的最严格的编译警告等级
1）程序员必须提供新的代码，以及文件差异分析工具
2）复审者可以选择面对面的复审、独立复审或其他方式
3）复审者必须把反馈意见逐一提出
4）对于复审的结果，我们团队必须要有一致的意见
二、项目数据库设计及其截图
数据库设计截图
三、项目ER图
ER图
四、主要功能流程描述
主要功能流程图
>校园资讯流程描述
>校园简历描述流程图
>教职工信息流程图
>娱乐圈流程图
>青大表白墙流程图
>青大新闻流程图
>青大贴吧流程图
