View on GitHub

Owl Movies

An online movies tickets system.

生产规范与指南

8.1 Owl Movies 生产规范与指南

前端代码规范

JavaScript规范

1.使用空格代替tab进行缩进

使用两个空格代替tab键，对代码进行缩进管理。

2.不能省略分号

每个语句必须以分号结尾，不允许依赖于JS自动添加分号的功能。

3.杜绝var

使用const或let来声明所有局部变量。如果变量不需要被重新赋值，默认应该使用const。

4.使用模板字符串取代连接字符串

在处理多行字符串时，使用模板字符串代替+号连接字符串

5.不要使用eval语句

6.常量的命名规范

常量命名应该使用全大写格式，并用下划线分割，如：

const MAX_LENGTH = 100;

7.使用单引号

只允许使用单引号包裹普通字符串，禁止使用双引号。

项目文件规范

1.文件命名由多个单词组成，采用中划线连接

2.文件名称只由小写英文字母、数字、中划线组成，不应包含特殊符号

3.每个页面的默认入口文件应当命名为index.vue

4.公共组件统一放置在components文件夹中；页面组件统一放置在pages文件夹中，每个页面的文件夹命名参考文件命名规则

5.父组件与子组件间应当以目录结构的方式表现出层级关系，如子组件放置在childrens文件夹中，且childrens文件夹与父组件放置在同一目录下

后端代码规范

本项目后端拟采用Python+Django实现，所以主要定义Python编码的规范。

分号

不要在行尾加分号, 也不要用分号将两条命令放在同一行。

行长度

每行不超过80个字符

以下情况除外：

  1. 长的导入模块语句
  2. 注释里的URL

尽量不使用反斜杠连接行，Python会将 圆括号, 中括号和花括号中的行隐式的连接起来 , 可以利用这个特点。

例如：

foo_bar(self, width, height, color='black', design=None, x='foo',
             emphasis=None, highlight=0)

if (width == 0 and height == 0 and
         color == 'red' and emphasis == 'strong'):

括号

宁缺毋滥的使用括号

除非是用于实现行连接或者是用于元组, 否则不要在返回语句或条件语句中使用括号.

No:
	return (foo)

缩进

用4个空格来缩进代码，绝对不要用tab， 也不要tab和空格混用。

  1. tab对于需要共享的代码而言是灾难。
  2. 不同编辑器对空格的显示逻辑总是一样的，但是对于tab却五花八门。

使用sublime或者其他编辑器的项目成员，可以设置编辑器用4个空格替代tab。

空行

顶级定义之间空两行, 方法定义之间空一行。

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

空格

按照标准的排版规范来使用标点两边的空格

括号内不要有空格.

按照标准的排版规范来使用标点两边的空格

Yes: spam(ham[1], {eggs: 2}, [])
No:  spam( ham[ 1 ], { eggs: 2 }, [ ] )

注释

请尽量添加注释，确保对模块, 函数, 方法和行内注释使用正确的风格。

文件和Sockets

在文件和sockets结束时, 显式的关闭它.

除文件外, sockets或其他类似文件的对象在没有必要的情况下打开, 会有许多副作用, 例如:

  1. 它们可能会消耗有限的系统资源, 如文件描述符. 如果这些资源在使用后没有及时归还系统, 那么用于处理这些对象的代码会将资源消耗殆尽.
  2. 持有文件将会阻止对于文件的其他诸如移动、删除之类的操作.
  3. 仅仅是从逻辑上关闭文件和sockets, 那么它们仍然可能会被其共享的程序在无意中进行读或者写操作. 只有当它们真正被关闭后, 对于它们尝试进行读或者写操作将会跑出异常, 并使得问题快速显现出来.

而且, 幻想当文件对象析构时, 文件和sockets会自动关闭, 试图将文件对象的生命周期和文件的状态绑定在一起的想法, 都是不现实的. 因为有如下原因:

  1. 没有任何方法可以确保运行环境会真正的执行文件的析构. 不同的Python实现采用不同的内存管理技术, 比如延时垃圾处理机制. 延时垃圾处理机制可能会导致对象生命周期被任意无限制的延长.
  2. 对于文件意外的引用,会导致对于文件的持有时间超出预期(比如对于异常的跟踪, 包含有全局变量等).

导入格式

导入总应该放在文件顶部, 位于模块注释和文档字符串之后, 模块全局变量和常量之前. 导入应该按照从最通用到最不通用的顺序分组:

  1. 标准库导入
  2. 第三方库导入
  3. 应用程序指定导入

推荐：每种分组中, 应该根据每个模块的完整包路径按字典序排序, 忽略大小写.

命名

应该避免的名称

  1. 单字符名称, 除了计数器和迭代器.
  2. 包/模块名中的连字符(-)
  3. 双下划线开头并结尾的名称(Python保留, 例如__init__)

命名约定

  1. 所谓”内部(Internal)”表示仅模块内可用, 或者, 在类内是保护或私有的.
  2. 用单下划线(_)开头表示模块变量或函数是protected的(使用import * from时不会包含).
  3. 用双下划线(__)开头的实例变量或方法表示类内私有.
  4. 将相关的类和顶级函数放在同一个模块里. 不像Java, 没必要限制一个类一个模块.
  5. 对类名使用大写字母开头的单词(如CapWords, 即Pascal风格), 但是模块名应该用小写加下划线的方式(如lower_with_under.py). 尽管已经有很多现存的模块使用类似于CapWords.py这样的命名, 但现在已经不鼓励这样做, 因为如果模块名碰巧和类名一致, 这会让人困扰.