规范化eslint插件安装

  1. 安装ts环境 有的话跳过
npm install typescript
  1. vscode插件栏下载ESlint插件
  2. ctrl+shift+p 搜索settings，找到open settings(json)打开，新增如下配置
"eslint.autoFixOnSave": true,
"eslint.validate": [
    "javascript",
    "typescript",
],
"editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
}

安装成功后，以下部分规范（根目录下.eslintrc.js内规范）将会在编辑阶段实时监测。有不符合规范情况，直接抛出异常（保存可自动修复部分异常）

一、编程规范

（一）命名：

  1. 类名使用 UpperCamelCase 风格，必须遵从驼峰形式，（领域模型的除外DO / BO / DTO / VO 等）
  2. 类名要和文件名一致。
  3. 方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从驼峰形式。
  4. 抽象类命名使用 Abstract 或 Base 开头 ； 异常类命名使用 Exception 结尾 ； 测试类命名以它要测试的类的名称开始，以 Test 结尾。
  5. 枚举类名建议带上 Enum 前缀，枚举成员名称需要全大写，单词间用下划线隔开。
  6. 方法命名规约（建议）
    1 ） 获取单个对象的方法用 get 做前缀。
    2 ） 获取多个对象的方法用 list 做后缀（习惯：getXXXList）
    3 ） 获取统计值的方法用 count 做后缀。
    4 ) 修改操作更新方法用 refresh 做前缀。

（二）接口方法定义

  1. 接口类中的方法和属性不要加任何修饰符号（public 也不要加）
  2. 类成员与方法访问控制从严：
    1） 如果不允许外部直接通过 new 来创建对象，那么构造方法必须是 private。
    2） 工具类不允许有 public 或 default 构造方法。
    3） 类非 static 成员变量并且与子类共享，必须是 protected。
    4） 类非 static 成员变量并且仅在本类使用，必须是 private。
    5） 类 static 成员变量如果仅在本类使用，必须是 private。
    6） 若是 static 成员变量，必须考虑是否为 final。
    7） 类成员方法只供类内部调用，必须是 private。
    8） 类成员方法只对继承类公开，那么限制为 protected。
    说明： 任何类、方法、参数、变量，严控访问范围。过于宽泛的访问范围，不利于模块解耦。

（三）常量定义

  • 常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

（四）变量声明

  1. 使用let/const代替var
  2. 禁止出现未使用过的变量

（五）其他

  1. 对象和类中的getter和setter必须成对出现
  2. 禁止使用多个空格
  3. 块级注释前有空行
  4. 不允许代码后跟内联注释
  5. 要求箭头函数体使用大括号
  6. 要求箭头函数的参数使用圆括号

二、格式规范：

（一）注释规范

  1. 类、类属性、类方法的注释必须使用 Javadoc 规范，使用/*内容/格式，不得使用//xxx 方式。
  2. 所有的枚举类型字段必须要有注释，说明每个数据项的用途。
  3. 待办事宜需要注释 // TODO 或者 // … 来做好标记。
  4. 错误代码，不能工作需要注释 // FIXME 。
  5. 代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
  6. 合理处理注释掉的代码。 在上方详细说明，而不是简单的注释掉。 如果无用，则删除。
    说明： 代码被注释掉有两种可能性：
    1） 后续会恢复此段代码逻辑。 (如果没有备注信息，难以知晓注释动机。)
    2） 永久不用。(建议直接删掉（代码仓库保存了历史代码） 。)
  7. 对于注释的要求：
    第一、能够准确反应设计思想和代码逻辑；
    第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。

（二）风格规范

  1. 单行太长需换行。
  2. 方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。相同业务逻辑和语义之间不需要插入空行。
  3. 构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中。

三、工程结构：

（1）分层领域规范

  • 工程目录中要包含项目目录（main）、配置目录（config）、文档目录（doc）、升级记录目录（backLog）等。
  • 框架层代码要和逻辑代码区分目录。
  • 业务逻辑和工具类区分目录。
  • 视图分离，管理类，模块类区分目录。
  • 所需第三方库、SDK区分目录。

四、代码提交：

  • 注意忽略目录、临时文件。
  • 认真填写 commit message。
  • 注意合并代码冲突。