规范，是指群体所确立的行为标准，是一个企业内部各个工作岗位、各个工作流程明文规定的标准，是我们工作中的行为准则。

前端规范的目的

规范的目的是为了编写高质量的代码，让你的团队成员每天得心情都是愉悦的，大家在一起是快乐的。

现代软件架构的复杂性需要协同开发完成，如何高效地协同呢？无规矩不成方圆，无规范难以协同，比如，制订交通法规表面上是要限制行车权，实际上是保障公众的人身安全，试想如果没有限速，没有红绿灯，谁还敢上路行驶。对软件来说，适当的规范和标准绝不是消灭代码内容的创造性、优雅性，而是限制过度个性化，以一种普遍认可的统一方式一起做事，提升协作效率，降低沟通成本。代码的字里行间流淌的是软件系统的血液，质量的提升是尽可能少踩坑，杜绝踩重复的坑，切实提升系统稳定性，码出质量。 —— 《阿里规约》

如何保证前端代码规范

我们都知道项目中中都会存在一定的规范，但是一半代码的规范具体表现在哪些部分呢。其实在我的理解中，大致分为两个部分。一是代码层级规范化；二是通过前端工程化实现规范化。

代码约束实现前端代码规范化

其实这个是比较好理解的，就是在我们写代码的时候，我们需要知道我们到底在写什么。可以通过规范化文档去实现我们的代码。

以我最近的项目为例，类似于HTML，CSS规范之类的这里就不再多描述

文件

项目文件夹/静态资源命名

全部采用小写并以中划线分隔。

正例：biz-module

反例：bizModule or biz_module

自定义组件

统一使用大驼峰命名

正例：BizModule

反例：bizModule or biz_module

页面模块

统一使用小驼峰命名

正例：bizModule

反例：BizModule or biz_module

代码

异步请求

统一使用async/await

正例： await getUserData() 反例： getUserData().then(res => {})

自定义样式

对于less文件覆盖umi样式，统一使用adm-*为前缀；自定义样式使用com-*为前缀

例子：

// 覆盖类样式，依然使用 .adm- 前缀 .adm-button { ... }

// 覆盖叠加类样式，使用 .com- 前缀 .adm-nav-bar.com-nav-bar-immersive { ... }

// 公共自定义样式，使用 .com- 前缀 .com-test { ... }

常量

统一使用全大写并有下划线连接

正例： CONST_VALUE 反例： const_value/constValue

工程化

ESLint

可组装的JavaScript和JSX检查工具

具体文档可参考ESLint中文文档：eslint.cn/

ESLint是一个组装的Js和JSX工具。这是官网上的一句话。在项目中，主要目的是提示代码的格式是否符合lint config匹配文件。可以依赖代码工具进行代码检查.

配置文件格式：

module.exports = {
  extends: ['default/eslint-config-loan/react-typescript'],
  rules: {
    '@typescript-eslint/strict-boolean-expressions': 0,
    'no-redeclare': 0
  },
  parserOptions: {
    project: './tsconfig.json'
  },
  env: {
    browser: true,
    es6: true,
    jest: true
  }
}

Prettier

Prettier 主要是配合ESLint对代码进行自动的格式化处理。同时也会统一由于不同IDE导致缩进的问题。

我们会在package.json中配置prettier命令

"prettier": "prettier --write '**/*.{js,jsx,tsx,ts,less,md,json}'",

Git Commit

对于代码的提交，我们需要去验证代码是否符合Lint规范和正确的commit信息。精确的commit信息也会帮助我们理解每个提交是具体做了什么事情。

在package.json中，我们会配置如下命令

  "gitHooks": {
    "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS",
    "pre-commit": "lint-staged"
  },
  "lint-staged": {
    "*.{js,jsx,less,md,json}": [
      "prettier --write"
    ],
    "*.ts?(x)": [
      "prettier --parser=typescript --write"
    ]
  },

额外

这里其实没有具体规范，可以用来当作参考。

get 获取/set 设置,
add 增加/remove 删除
create 创建/destory 移除
start 启动/stop 停止
open 打开/close 关闭,
read 读取/write 写入
load 载入/save 保存,
create 创建/destroy 销毁
begin 开始/end 结束,
backup 备份/restore 恢复
import 导入/export 导出,
split 分割/merge 合并
inject 注入/extract 提取,
attach 附着/detach 脱离
bind 绑定/separate 分离,
view 查看/browse 浏览
edit 编辑/modify 修改,
select 选取/mark 标记
copy 复制/paste 粘贴,
undo 撤销/redo 重做
insert 插入/delete 移除,
add 加入/append 添加
clean 清理/clear 清除,
index 索引/sort 排序
find 查找/search 搜索,
increase 增加/decrease 减少
play 播放/pause 暂停,
launch 启动/run 运行
compile 编译/execute 执行,
debug 调试/trace 跟踪
observe 观察/listen 监听,
build 构建/publish 发布
input 输入/output 输出,
encode 编码/decode 解码
encrypt 加密/decrypt 解密,
compress 压缩/decompress 解压缩
pack 打包/unpack 解包,
parse 解析/emit 生成
connect 连接/disconnect 断开,
send 发送/receive 接收
download 下载/upload 上传,
refresh 刷新/synchronize 同步
update 更新/revert 复原,
lock 锁定/unlock 解锁
check out 签出/check in 签入,
submit 提交/commit 交付
push 推/pull 拉,
expand 展开/collapse 折叠
begin 起始/end 结束,
start 开始/finish 完成
enter 进入/exit 退出,
abort 放弃/quit 离开
obsolete 废弃/depreciate 废旧,
collect 收集/aggregate 聚集

结束语

2022.1.28

木更

关于如何规范前端团队代码