代码规范执行方案：让团队协作更顺畅的实战策略

在日常开发中，你有没有遇到过这样的场景？打开同事提交的代码文件，缩进混乱、命名随意，函数像一堵墙一样长，看得人头晕眼花。更尴尬的是，自己一周前写的代码，现在再看也像别人写的。这种情况不仅拖慢进度，还容易埋下bug。

为什么需要代码规范执行方案

一个项目多人参与时，每个人的编码习惯不同。有人喜欢用单引号，有人偏爱双引号；有人写函数一行搞定，有人层层嵌套。这些差异积累下来，会让代码库变得难以维护。

制定一套清晰的代码规范并严格执行，不是为了束缚手脚，而是为了让团队沟通更高效。就像交通规则，大家都靠右行驶，才不容易撞车。

从 ESLint 开始落地规范

以 JavaScript 项目为例，ESLint 是最常用的工具之一。通过配置 .eslintrc.js 文件，可以定义哪些写法允许，哪些禁止。

module.exports = {
  env: {
    browser: true,
    es2021: true
  },
  extends: [
    'eslint:recommended'
  ],
  rules: {
    'no-unused-vars': 'warn',
    'no-console': 'off',
    'indent': ['error', 2],
    'quotes': ['error', 'single']
  }
};

上面这个配置要求使用两个空格缩进、单引号字符串，并对未使用的变量发出警告。一旦有人提交不符合规则的代码，就会被提示甚至阻断。

结合 Git Hooks 自动拦截

光有规则不够，得让它真正起作用。借助 Husky 这样的工具，可以在代码提交前自动运行检查。

比如在 .husky/pre-commit 中加入：

#!/bin/sh
npm run lint

这样每次执行 git commit 时，都会先跑一遍 ESLint。如果有错误，提交就会被拒绝，直到问题修复为止。相当于给代码入口装了个安检门。

Prettier 统一格式细节

除了语法层面的检查，代码的“颜值”也很重要。Prettier 可以统一处理空格、换行、括号位置等细节问题。

安装后，在项目根目录添加 .prettierrc 配置：

{
  "semi": true,
  "trailingComma": "all",
  "singleQuote": true,
  "printWidth": 80
}

保存文件时，编辑器会自动按规则格式化。再也不用争论“逗号到底要不要加”这种问题了。

团队协作中的实际效果

某次我们接手一个老项目，原始代码没有统一风格。上线前两周，团队决定引入上述方案。起初有人抱怨“太严格”，但一周后明显感觉代码阅读速度快了，合并冲突也少了。

特别是新人加入时，不再需要花几天时间适应各种奇怪的写法，开箱即用的规则让他们快速融入。

别忘了文档和培训

工具只是手段，关键还是人的认知一致。我们把代码规范整理成一份简明文档，放在 Wiki 首页。新成员入职第一天，就带着他们走一遍检查流程。

偶尔组织一次“代码评审小课堂”，挑出典型片段讨论优化方式，比单纯说教更有说服力。