代码格式不规范?有这个标准就够了!

规范化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。
  • 注意合并代码冲突

猜你喜欢

转载自blog.csdn.net/qq_37904209/article/details/109055689