大厂编程规范

编程规范

代码检测工具 ESLint

ESLint 是 13 年创建的开源项目，目标就是 提供一个插件化的 javascript 代码检测工具 。随着对代码格式的规范性越来越重视，eslint 也逐渐被更多的人所接收，同时也有很多大厂在原有的 eslint 规则基础之上进行了一些延伸。这里选择标准的 eslint 规则

? Pick a linter / formatter config: 
  ESLint with error prevention only // 仅包含错误的 ESLint
  ESLint + Airbnb config // Airbnb 的 ESLint 延伸规则
  ESLint + Standard config // 标准的 ESLint 规则

打开项目中的 .eslintrc.js 文件，ESLint 配置文件遵循 commonJS 的导出规则，导出的对象就是 ESLint 的配置对象。文档：https://eslint.bootcss.com/docs/user-guide/configuring

module.exports = {
  root: true, // 表示当前目录即为根目录，ESLint 规则将被限制到该目录下
  // env 表示启用 ESLint 检测的环境，在 node 环境下启动 ESLint 检测
  env: {
    node: true
  },
  // ESLint 中基础配置需要继承的配置
  extends: ["plugin:vue/vue3-essential", "@vue/standard"],
  // 解析器
  parserOptions: {
    parser: "babel-eslint"
  },
  rules: {
    "no-console": process.env.NODE_ENV === "production" ? "warn" : "off",
    "no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off"
  }
};

在 .eslintrc.js 文件中，新增一条验证规则

json

"quotes": "error" // 默认
"quotes": "warn" // 修改为警告
"quotes": "off" // 修改不校验

代码格式化 Prettier

ESLint 可以让代码格式变得更加规范，但是同样的它也会带来开发时编码复杂度上升的问题。prettier 既可以保证 ESLint 规则校验，又可以让开发者无需关注格式问题来进行顺畅的开发

prettier 官网

prettier 是一个开箱即用的代码格式化工具，可以直接集成到 VSCode 之中。在保存时，让代码直接符合 ESLint 标准（需要通过一些简单配置

VSCode 配置 prettier

VSCode 中安装 prettier 插件，在项目中新建 .prettierrc 文件，该文件为 perttier 默认配置文件

json

{
  "semi": false, // 不尾随分号
  "singleQuote": true, // 使用单引号
  "trailingComma": "none" // 多行逗号分割的语法中，最后一行不加逗号
}

打开 VSCode 设置，在设置中搜索 save ，勾选 Format On Save

prettier 与 eslint 冲突

当是 prettier 和 ESLint 的发生冲突问题，打开 .eslintrc.js 配置文件，在 rules 规则下，新增一条规则。关闭冲突的规则

git 规范

Commitizen 规范化提交代码

commitizen 就是 git 提交规范化工具 ，commitizen 仓库名为 cz-cli ，它提供 git cz 的指令用于代替 git commit

安装 Commitizen 与 cz-customizable 插件

bash

# 不指定版本
pnpm install commitizen cz-customizable -D

添加以下配置到 package.json 中

json

{
  "config": {
    "commitizen": {
      "path": "node_modules/cz-customizable"
    }
  }
}

在项目根目录下创建 .cz-config.js 自定义提示文件

module.exports = {
  // 可选类型
  types: [
    { value: 'feat', name: 'feat:     新功能' },
    { value: 'fix', name: 'fix:      修复' },
    { value: 'docs', name: 'docs:     文档变更' },
    { value: 'style', name: 'style:    代码格式(不影响代码运行的变动)' },
    {
      value: 'refactor',
      name: 'refactor: 重构(既不是增加feature，也不是修复bug)'
    },
    { value: 'perf', name: 'perf:     性能优化' },
    { value: 'test', name: 'test:     增加测试' },
    { value: 'chore', name: 'chore:    构建过程或辅助工具的变动' },
    { value: 'revert', name: 'revert:   回退' },
    { value: 'build', name: 'build:    打包' }
  ],
  // 消息步骤
  messages: {
    type: '请选择提交类型:',
    customScope: '请输入修改范围(可选):',
    subject: '请简要描述提交(必填):',
    body: '请输入详细描述(可选):',
    footer: '请输入要关闭的issue(可选):',
    confirmCommit: '确认使用以上信息提交？(y/n/e/h)'
  },
  // 跳过问题
  skipQuestions: ['body', 'footer'],
  // subject文字长度默认是72
  subjectLimit: 72
}

使用 git cz 代替 git commit 即可看到提示内容。但是每次必须要通过 git cz 指令才可以完成规范化提交！

husky + commitlint 检查提交规范

commitlint：用于检查提交信息
husky：是git hooks工具

注意：npm 需要在 7.x 以上版本！！！！！

commitlint

bash

npm install @commitlint/config-conventional@12.1.4 @commitlint/cli@12.1.4 -D

创建 commitlint.config.js 文件，增加配置项（ config-conventional 默认配置点击可查看）：

module.exports = {
  // 继承的规则
  extends: ['@commitlint/config-conventional'],
  // 定义规则类型
  rules: {
    // type 类型定义，表示 git 提交的 type 必须在以下类型范围内
    'type-enum': [
      2,
      'always',
      [
        'feat', // 新功能 feature
        'fix', // 修复 bug
        'docs', // 文档注释
        'style', // 代码格式(不影响代码运行的变动)
        'refactor', // 重构(既不增加新功能，也不是修复bug)
        'perf', // 性能优化
        'test', // 增加测试
        'chore', // 构建过程或辅助工具的变动
        'revert', // 回退
        'build' // 打包
      ]
    ],
    // subject 大小写不做校验
    'subject-case': [0]
  }
}

注意：确保保存为 UTF-8 的编码格式

husky

bash

npm install husky@7.0.1 -D

# 启动 hooks,生成 .husky 文件夹
npx husky install

在 package.json 中生成 prepare 指令（ 需要 npm > 7.0 版本 ）

code

npm set-script prepare "husky install"

执行 prepare 指令，执行成功提示 husky -Git hooks installed

code

npm run prepare

添加 commitlint 的 hook 到 husky中，并指令在 commit-msg 的 hooks 下执行 npx --no-install commitlint --edit "$1" 指令

code

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

那么至此，就已经可以处理好了 强制规范化的提交要求，到现在 不符合规范的提交信息，将不可在被提交！

pre-commit 检测提交时代码规范

在 ESLint 与 Prettier 配合解决代码本地代码格式问题。 但是这样的格式处理问题，只能够在本地进行处理，并且还需要 手动在 VSCode 中配置自动保存 。就会存在一个问题，要是有人忘记配置自动保存

通过 husky 监测 pre-commit 钩子，在该钩子下执行 npx eslint --ext .js,.vue src 指令来去进行相关检测：

执行 npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src" 添加 commit 时的 hook （npx eslint --ext .js,.vue src 会在执行到该 hook 时运行）
该操作会生成对应文件 pre-commit
关闭 VSCode 的自动保存操作
修改一处代码，使其不符合 ESLint 校验规则
执行 提交操作 会发现，抛出一系列的错误，代码无法提交
想要提交代码，必须处理完成所有的错误信息

bash

npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src"

那么到这里位置，我们已经通过 pre-commit 检测到了代码的提交规范问题。

错误的代码格式可能会抛出很多的 ESLint 错误，让人看得头皮发麻。严重影响程序猿的幸福指数。

那么有没有办法，让程序猿在 0 配置的前提下，哪怕代码格式再乱，也可以 ”自动“ 帮助他修复对应的问题，并且完成提交呢？

lint-staged 自动修复格式错误

通过 pre-commit 处理 检测代码的提交规范问题，但进行代码提交时，会检测所有的代码格式规范 。

lint-staged 可以让当前的代码检查 只检查本次修改更新的代码，并在出现错误的时候，自动修复并且推送

lint-staged 无需单独安装，生成项目时 vue-cli 已经安装过了

修改 package.json 配置

json

"lint-staged": {
    "src/**/*.{js,vue}": [
      "eslint --fix",
      "git add"
    ]
  }

如上配置，每次它只会在你本地 commit 之前，校验你提交的内容是否符合你本地配置的 eslint规则，校验会出现两种结果：
1. 如果符合规则：则会提交成功。
2. 如果不符合规则：它会自动执行 eslint --fix 尝试帮你自动修复，如果修复成功则会帮你把修复好的代码提交，如果失败，则会提示你错误，让你修好这个错误之后才能允许你提交代码。

修改 .husky/pre-commit 文件

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

再次执行提交代码 git cz
发现 暂存区中 不符合 ESlint 的内容，被自动修复

补充：Git Hooks

使用了 git cz 来代替了 git commit 实现了规范化的提交诉求，但是依然存在着有人会忘记使用的问题。Git Hooks git 在执行某个事件之前或之后进行一些其他额外的操作

Git Hook	调用时机	说明
pre-applypatch	`git am` 执行前
applypatch-msg	`git am` 执行前
post-applypatch	`git am` 执行后	不影响`git am`的结果
pre-commit	`git commit` 执行前	可以用`git commit --no-verify`绕过
commit-msg	`git commit` 执行前	可以用`git commit --no-verify`绕过
post-commit	`git commit` 执行后	不影响`git commit`的结果
pre-merge-commit	`git merge` 执行前	可以用`git merge --no-verify`绕过。
prepare-commit-msg	`git commit`执行后，编辑器打开之前
pre-rebase	`git rebase`执行前
post-checkout	`git checkout`或`git switch`执行后	如果不使用`--no-checkout`参数，则在`git clone`之后也会执行。
post-merge	`git commit`执行后	在执行`git pull`时也会被调用
pre-push	`git push`执行前
pre-receive	`git-receive-pack`执行前
update
post-receive	`git-receive-pack`执行后	不影响`git-receive-pack`的结果
post-update	当 `git-receive-pack`对 `git push` 作出反应并更新仓库中的引用时
push-to-checkout	当``git-receive-pack`对`git push`做出反应并更新仓库中的引用时，以及当推送试图更新当前被签出的分支且`receive.denyCurrentBranch`配置被设置为`updateInstead`时
pre-auto-gc	`git gc --auto`执行前
post-rewrite	执行`git commit --amend`或`git rebase`时
sendemail-validate	`git send-email`执行前
fsmonitor-watchman	配置`core.fsmonitor`被设置为`.git/hooks/fsmonitor-watchman`或`.git/hooks/fsmonitor-watchmanv2`时
p4-pre-submit	`git-p4 submit`执行前	可以用`git-p4 submit --no-verify`绕过
p4-prepare-changelist	`git-p4 submit`执行后，编辑器启动前	可以用`git-p4 submit --no-verify`绕过
p4-changelist	`git-p4 submit`执行并编辑完`changelist message`后	可以用`git-p4 submit --no-verify`绕过
p4-post-changelist	`git-p4 submit`执行后
post-index-change	索引被写入到`read-cache.c do_write_locked_index`后

整体的 hooks 非常多但其中用的比较多的其实只有两个：

Git Hook	调用时机	说明
pre-commit	`git commit` 执行前它不接受任何参数，并且在获取提交日志消息并进行提交之前被调用。脚本`git commit`以非零状态退出会导致命令在创建提交之前中止。	可以用`git commit --no-verify`绕过
commit-msg	`git commit` 执行前可用于将消息规范化为某种项目标准格式。还可用于在检查消息文件后拒绝提交。	可以用`git commit --no-verify`绕过

前端代码评审 Checklist

工具（ESLint / Prettier / husky）只能保证格式与提交规范，真正的质量还需要人工 Code Review。下面是一份前端代码评审维度清单，建议在 PR 合并前逐项核对。

可读性

命名是否语义清晰（变量/函数/组件名能否自解释）
复杂逻辑是否有必要注释（讲「为什么」而非「是什么」）
函数/组件是否过长（单函数建议 ≤ 50 行，过长应拆分）
嵌套层级是否过深（超过 3 层考虑早返回或提取）

健壮性

边界条件是否处理（空数组、null、undefined、0、NaN）
异步操作是否有错误处理（Promise / try-catch / await）
用户输入是否校验与转义（防止 XSS、SQL 注入）
第三方接口是否考虑超时、降级与重试

安全性

是否避免硬编码密码、Token、密钥等敏感信息
是否对用户输入做转义（渲染到 DOM 前）
是否启用了必要的 HTTP 安全头（CSP 等，见 helmet）
权限校验是否在后端兜底（前端校验仅体验，不可信）

性能

是否存在不必要的重渲染（React/Vue 的 memo、computed 使用）
大列表是否使用虚拟滚动或分页
图片/资源是否做了懒加载与合理压缩
是否存在内存泄漏（未清理的定时器、事件监听、订阅）

可维护性与可测试性

是否遵循单一职责，模块间耦合是否过低
业务逻辑是否从 UI 中抽离（便于单测）
关键逻辑是否有单元测试覆盖
是否避免了魔数（提取为具名常量）

评审原则：先对齐规范与架构，再抠细节。优先质疑「为什么这样设计」，其次才是「代码写得好不好」。