编码规范

CodeStyle, 代码风格

一 Code Style

1. 使用 arrow 函数代替匿名函数表达式。
2. 只要需要的时候才把 arrow 函数的参数括起来。 比如，(x) => x + x 是错误的，下面是正确的做法： i. x => x + x ii. (x,y) => x + y iii. <T>(x: T, y: T) => x === y
3. 总是使用 {} 把循环体和条件语句括起来。
4. 开始的 { 总是在同一行。
5. 小括号里开始不要有空白. 逗号，冒号，分号后要有一个空格。比如： i. for (var i = 0, n = str.length; i < 10; i++) { } ii. if (x < 10) { } iii. function f(x: number, y: string): void { }
6. 每个变量声明语句只声明一个变量 （比如 使用 var x = 1; var y = 2; 而不是 var x = 1, y = 2;）。
7. else 要在结束的 } 后另起一行。

二 Git Style

Commit message Style 规范在 rrd-fe 落地使用情况

参考原文: 针对团队目前使用的情况，我们讨论后拟定了commit message每一部分的填写规则。

1. type

type为必填项，用于指定commit的类型，约定了feat、fix两个主要type，以及docs、style、build、refactor、revert五个特殊type，其余type暂不使用。

# 主要type
feat:     增加新功能
fix:      修复bug

# 特殊type
docs:     只改动了文档相关的内容
style:    不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build:    构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert:   执行git revert打印的message

# 暂不使用type
test:     添加测试或者修改现有测试
perf:     提高性能的改动
ci:       与CI（持续集成服务）有关的改动
chore:    不修改src或者test的其余修改，例如构建过程或辅助工具的变动

当一次改动包括主要type与特殊type时，统一采用主要type。

2. scope

scope也为必填项，用于描述改动的范围，格式为项目名/模块名，例如： node-pc/common rrd-h5/activity，而we-sdk不需指定模块名。如果一次commit修改多个模块，建议拆分成多次commit，以便更好追踪和维护。

3. body

body填写详细描述，主要描述改动之前的情况及修改动机，对于小的修改不作要求，但是重大需求、更新等必须添加body来作说明。

4. break changes

break changes指明是否产生了破坏性修改，涉及break changes的改动必须指明该项，类似版本升级、接口参数减少、接口删除、迁移等。

5. affect issues

affect issues指明是否影响了某个问题。例如我们使用jira时，我们在commit message中可以填写其影响的JIRA_ID，若要开启该功能需要先打通jira与gitlab。参考文档：https://docs.gitlab.com/ee/user/project/integrations/jira.html

填写方式例如：

re #JIRA_ID
fix #JIRA_ID