• 团队成员
  组长：1500802096 马柯宇
  组员：1500802091 张安祺
  1500802095 包明珍
  1500802100 王旭文
  1500802120 苏 桂

一、代码规范

• PHP代码规范：
  （1）文档格式

1）对于只含有 php 代码的文件，我们将在文件结尾处忽略掉 "?>" 。这是为了防止多余的空格或者其它字符影响到代码。
例如：
<?php
$foo = 'foo';

2） 缩进应该能够反映出代码的逻辑结果，尽量使用四个空格，禁止使用制表符TAB，因为这样能够保证有跨客户端编程器软件的灵活性。
例如：
if (1 == $x) {
    $indented_code = 1;
    if (1 == $new_line) {
        $more_indented_code = 1;
    }
}

3） 变量赋值必须保持相等间距和排列。
例如：
$variable = 'demo';
$var      = 'demo2';

4 ）每行代码长度应控制在80个字符以内，最长不超过120个字符。因为 linux 读入文件一般以80列为单位，就是说如果一行代码超过80个字符，那么系统将为此付出额外操作指令。这个虽然看起来是小问题，但是对于追求完美的程序员来说也是值得注意并遵守的规范。

5） 每行结尾不允许有多余的空格。
（2）命名约定
1)通常类文件都是以“.class.php“为后缀，且类文件名只允许字母。

2)配置和函数等其他类库文件之外的文件一般是分别以“.inc.php“和”.php“为后缀。

3)确保文件的命名和调用大小写一致。

4)类名和文件名一致。

5)大括号的开始必须在类名的下一行顶格。

6)类中的所有代码都必须用四个空格来进行缩进。

（3）通常约定
代码缩进全部用tab，在编辑器里面设置tab存为制表符，不要存为空格。不要打一堆空格来做缩进。
SVN / Git 中新建文件编码类型统一用utf-8编码（不带BOM）。
Unix 风格的换行: LF
所有可以直接访问的url中包含的文件名都是小写，如果是多个词组成，则用下划线连接。
大括号的开始必须在类名的下一行顶格。
行宽：120 字符
类中的所有代码都必须用四个空格来进行缩进。

• Python的代码规范
  （1）基本规范
  1）分号
  不要在行尾加分号, 也不要用分号将两条命令放在同一行。

2）行长度
每行不超过80个字符
以下情况除外：
a.长的导入模块语句
b.注释里的URL
不要使用反斜杠连接行。
Python会将 圆括号, 中括号和花括号中的行隐式的连接起来 , 你可以利用这个特点. 如果需要, 你可以在表达式外围增加一对额外的圆括号。

3）括号
宁缺毋滥的使用括号除非是用于实现行连接, 否则不要在返回语句或条件语句中使用括号. 不过在元组两边使用括号是可以的.

4）缩进
用4个空格来缩进代码绝对不要用tab, 也不要tab和空格混用.

5）空行
顶级定义之间空两行, 方法定义之间空一行顶级定义之间空两行, 比如函数或者类定义. 方法定义, 类定义与第一个方法之间, 都应该空一行. 函数或方法中, 某些地方要是你觉得合适, 就空一行.

6）空格
按照标准的排版规范来使用标点两边的空格括号内不要有空格按照标准的排版规范来使用标点两边的空格

7）注释
确保对模块, 函数, 方法和行内注释使用正确的风格

（2）类的代码规范
如果一个类不继承自其它类, 就显式的从object继承. 嵌套类也一样.
继承自 object 是为了使属性(properties)正常工作, 并且这样可以保护你的代码, 使其不受Python 3000的一个特殊的潜在不兼容性影响. 这样做也定义了一些特殊的方法, 这些方法实现了对象的默认语义, 包括 new, init, delattr, getattribute, setattr, hash, repr, and str .

（3）文件和sockets
在文件和sockets结束时, 显式的关闭它.
除文件外, sockets或其他类似文件的对象在没有必要的情况下打开, 会有许多副作用, 例如:
1）它们可能会消耗有限的系统资源, 如文件描述符. 如果这些资源在使用后没有及时归还系统, 那么用于处理这些对象的代码会将资源消耗殆尽.
2）持有文件将会阻止对于文件的其他诸如移动、删除之类的操作.
3）仅仅是从逻辑上关闭文件和sockets, 那么它们仍然可能会被其共享的程序在无意中进行读或者写操作. 只有当它们真正被关闭后, 对于它们尝试进行读或者写操作将会跑出异常, 并使得问题快速显现出来.
而且, 幻想当文件对象析构时, 文件和sockets会自动关闭, 试图将文件对象的生命周期和文件的状态绑定在一起的想法, 都是不现实的. 因为有如下原因:
1.没有任何方法可以确保运行环境会真正的执行文件的析构. 不同的Python实现采用不同的内存管理技术, 比如延时垃圾处理机制. 延时垃圾处理机制可能会导致对象生命周期被任意无限制的延长.
2.对于文件意外的引用,会导致对于文件的持有时间超出预期(比如对于异常的跟踪, 包含有全局变量等)。

（4）Main
即使是一个打算被用作脚本的文件, 也应该是可导入的. 并且简单的导入不应该导致这个脚本的主功能(main functionality)被执行, 这是一种副作用. 主功能应该放在一个main()函数中.
在Python中, pydoc以及单元测试要求模块必须是可导入的. 你的代码应该在执行主程序前总是检查 if name == 'main' , 这样当模块被导入时主程序就不会被执行.

• 系统代码规范：

• 代码风格原则：简明，易读，无二义性。

• 代码命名规范：

常量：全部大写
类名：大驼峰——首字母大写，其后单词首字母大写
方法变量名：小驼峰——首字母小写，其后单词首字母大写
变量名：小驼峰或下划线——全部小写，单词之间用下划线连接
系统保留：前置下划线（_），在命名中不要使用前置下划线。

• 代码书写规范：

(1)缩进：
统一使用4个空格。
函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格。

(2)行宽：
行宽必须限制，但是以前有些文档规定的80字符行宽太小了（以前的计算机/打字机显示行宽为80字符），现在时代不同了，可为100字符。

(3) 括号：
在复杂的条件表达式中，用括号清楚地表示逻辑优先级。

(4)断行与空白的{ }行：
每个“{”和“}”都独占一行。
关键词和操作符之间加适当的空格。

(5)分行：
不要把不同的变量定义在一行上。
不允许把多个短语句写在一行中，即一行只写一条语句。
较长的语句、表达式等要分成多行书写。
循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分。
若函数或过程中的参数较长，则要进行适当的划分。
相对独立的程序块与块之间加空行。

(6)注释:

a. 注释要简单明了。
b.注释放置的位置：对于比较短的注释（如变量的解释），不用另起一行注释，对于比较长的注释，要另起一行注释。对代码的注释应放在其上方相邻位置，不可放在下面。
c.注释（包括所有源代码）应只用ASCII字符，不要用中文或其他特殊字符，它们会极大地影响程序的可移植性。
d.边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。
格式：
//原代码 //Added/（Modified/ Deleted） by 开发者姓名 年-月-日; //因为业务原因修改的，要注明修改或删除原因） 新代码

e. 在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能描述；输入、输出及返回值说明；调用关系及被调用关系说明等。

(7)可读性：
a.避免使用不易理解的数字，用有意义的标识来替代。 
b.不要使用难懂的技巧性很高的语句。 
c.源程序中关系较为紧密的代码应尽可能相邻。

• 代码设计规范：
  (1)函数：
  a.绝大部分功能，都要在程序的函数中实现。
  b.函数的规模尽量限制在200行以内。 
  c.一个函数最好仅完成一件功能。  
  d.尽量不要编写依赖于其他函数内部实现的函数。 
  e.避免设计多参数函数，不使用的参数从接口中去掉。 
  f.函数名应准确描述函数的功能。 
  g.函数的返回值要清楚、明了，让使用者不容易忽视错误情况。 
  h.明确函数功能，精确（而不是近似）地实现函数设计。 
  i.减少函数本身或函数间的递归调用。

(2)错误处理：
（1）通常的法则是系统在正常状态并且用户正常操作下，不应产生任何异常。
（2）对可预见的错误不进行捕捉，而是在错误发生前通过条件判断避免发生。
（3）对不可预见或者难以解决错误进行try{…}catch(e){..}捕捉处理。
（4）对用户提出的错误进行后期处理

二、 团队项目的数据库设计

三、 团队项目的E-R图

四、 团队项目主要功能流程描述
（1）系统的整体框架：
系统分为视图层，控制层，模型层，数据层四个部分，用户通过视图层传递自己的需求，然后控制层做出相应的反馈，在模型层进行响应，改变状态，并且通知视图层已作出的修改。最后一块则是数据层，用来连接数据库，进行信息的存储。

（2）购买商品模块流程图：

（3）出售商品模块流程图：

（4）管理功能流程图：

（5）投诉功能流程图：

（6）留言板功能流程图：

五、 描述队员在此次作业中的分工
马柯宇：项目PM,统筹全局，代码规范，数据库的设计
王旭文：逐步改进需求规格说明书，绘制流程图
包明珍：撰写随笔，结构设计和界面设计，绘制流程图，E-R图
苏桂：代码规范的书写，绘制流程图
张安祺：代码规范的书写，测试，绘制流程图
六、 本次作业组员贡献分（总分=50）
马柯宇：11
王旭文：9
包明珍：11
苏 桂：9
张安祺：10