软件工程——团队作业3

软件工程——团队作业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图


四、主要功能流程描述

主要功能流程图

>校园资讯流程描述

>校园简历描述流程图

>教职工信息流程图

>娱乐圈流程图

>青大表白墙流程图

>青大新闻流程图

>青大贴吧流程图


五、团队分工

陕云鹏:任务分配,界面整理

杜永刚:数据库设计和代码原则

巩长胜:流程图设计

赵生云:流程图设计

舒心:ER图全功能制作

王佳铭:数据库设计的改善

张斌:流程图设计

posted @ 2017-05-31 19:58  Angle7  阅读(486)  评论(0编辑  收藏  举报