代码规范是指程序员在编码时应遵循的规则。 规范的目的是让程序员编写易于阅读和维护的代码。
试想一下，一个几十万行代码的项目，有好几种不同的代码规范，你看完之后是什么体验？ 即使使用空格或制表符进行代码缩进也会引起许多程序员的争论。 可以说，统一代码规范非常重要。
除了刚才提到的两点之外，统一代码规范还有其他好处：
•标准代码可以促进团队合作 •标准代码可以降低维护成本 •标准代码有助于codereview（代码审查） •培养代码规范的习惯，帮助程序员自我成长
当团队成员严格按照代码规范编写代码时，就能保证每个人的代码看起来就像是一个人写的。 看别人的代码就像看自己的代码一样（代码一致性），读起来越来越顺畅。 更重要的是，我们能够认识到规范的重要性，坚持规范的开发习惯。
如何制定代码规范
代码规范通常包括代码格式规范、变量和函数命名规范、文档注释规范等。
代码格式
通常是指代码是否用空格或制表符缩进、每行末尾是否加分号、左大括号是否需要换行等等。
命名约定
命名约定一般是指是否使用驼峰命名法、匈牙利命名法或帕斯卡命名法； 使用名词、名词组或动宾结构进行命名。
const smallObject = {} // 驼峰式，首字母小写
const SmallObject = {} // 帕斯卡式，首字母大写
const strName = 'strName' // 匈牙利式，前缀表示了变量是什么。这个前缀 str 表示了是一个字符串变量命名和函数命名的优缺点不同。
变量命名的重点是表明变量是什么，多采用名词来命名。 函数命名的要点是表明函数“做什么”，并且倾向于使用动宾结构来命名（动宾结构是doSomething）。
// 变量命名示例
const appleNum = 1
const sum = 10
// 函数命名示例
function formatDate() { ... }
function toArray() { ... }因为拼音同音字太多，所以不要用拼音来命名。
文档注释
文档注释比较简单，比如单行注释使用//，多行注释使用/**/。
/**
*
* @param {number} a
* @param {number} b
* @return {number}
*/
function add(a, b) {
return a + b
}
// 单行注释
const active = true如果想让团队从头开始制定代码规范，工作量会特别重，而且不现实。 因此，强烈建议寻找更好的开源代码规范，并在此基础上根据团队的需求进行个性化的修改。
下面列出了一些著名的 JavaScript 代码规范：
•airbnb（101kstar中文版）[1]、airbnb-英文版[2]•standard(24.5kstar)英文版[3]•百度后端编码规范3.9kstar[4]
CSS代码规范也有很多，比如：
•styleguide2.3kstar[5]•spec3.9kstar[6]
如何检测代码规范
规范制定后，如何确保严格执行？ 目前有两种方式：
1. 使用工具校准代码格式。 2. 使用codereview来审查变量命名和注释。
建议同时使用这两种方法，以确保严格执行代码规范。
我们来看看如何使用工具来校准代码格式。
ESLint
ESLint 最初是 Nicholas C. Zakas 在 2013 年 6 月创建的一个开源项目，其目标是提供一个插件式的 javascript 代码检查工具。
1.下载依赖
// eslint-config-airbnb-base 使用 airbnb 代码规范
npm i -D babel-eslint eslint eslint-config-airbnb-base eslint-plugin-import2.配置.eslintrc文件
{
"parserOptions": {
"ecmaVersion": 2019
},
"env": {
"es6": true,
},
"parser": "babel-eslint",
"extends": "airbnb-base",
}3. 在package.json的脚本中添加这行代码“lint”:“eslint--ext.jstest/src/”。 然后执行npmrunlint开始验证代码。 代码中的test/src/为待校准的代码目录，表示test和src目录下待检测的代码。
但这种方式检测代码的效率太低，每次都要自动检测。 如果报告错误，则必须自动更改代码。
为了改善以上缺点，我们可以使用VSCode。 使用它并添加适当的配置，你可以手动验证代码并在每次保存代码时进行低级格式化，省去了你这样做的麻烦（下一节将讲如何使用VSCode手动低级格式化）代码）。
风格林特
stylelint 是一个用于检测 CSS 代码格式的开源工具。 有关如何使用它的详细信息，请参阅下一节。
使用VSCode手动低格式代码低格式JavaScript代码
安装 VSCode，然后安装插件 ESLint。
选择File->Preference->Settings（如果安装了英文插件包，应该是File->Options->Settings），搜索eslintcss3规范，点击Editinsetting.json。
在配置文件中添加以下选项
"editor.codeActionsOnSave": {
"source.fixAll": true,
},配置完成后，VSCode 会根据你当前项目下的 .eslintrc 文件的规则来验证底层代码。
打字稿
如果要手动降级TypeScript，需要在NPM和VSCode中下载tsilnt插件：
npm i -D tslint
然后在项目中配置jslint文件。 它不能与eslint配置文件共享，并且规则不同。
另外，我发现tslint还有一些缺陷，比如低格式下手动缩进比较困难，可以通过shift+alt+f来实现。
扩张
如何低格式HTML、Vue（或其他后缀）文件中的HTML和CSS？
这就需要借助VSCode自带的低格式，快捷键是shift+alt+f。 假设 VSCode 当前正在打开一个 Vue 文件，按 shift+alt+f 会提示您选择低格式规范。 如果没有提示，说明已经有默认的低格式规范（通常是vetur插件），之后Vue文件中的所有代码都会低格式，但低格式规则也可以通过配置你自己。
具体规则如右图所示，您可以根据自己的喜好选择低级规则。
因为之前已经设置了 ESlint 的低级规则，Vue 文件只需要低级 HTML 和 CSS 代码，而不需要低级 JavaScript 代码，所以我们需要严格禁止 vetur 低级 JavaScript 代码：
按照上图配置完成后，回到刚才的vue文件。 随意乱乱代码的格式，然后按shift+alt+f，你会发现HTML和CSS中的代码已经被格式化了，而JavaScript中的代码还没有被格式化。 没关系，由于ESlint低格式已经设置好了，所以只要进行保存操作，JavaScript代码也会被手动低格式。
同理，其他类型的文件也可以通过这种方式设置低格式规范。
低格式 CSS 代码
下载依赖项
npm install --save-dev stylelint stylelint-config-standard在项目根目录下新建.stylelintrc.json文件，输入以下内容：
{
"extends": "stylelint-config-standard"
}VSCode 添加 stylelint 插件：
然后就可以看到效果了。
如果你想更改插件的默认规则，可以查看官方文档[7]，其中提供了170条规则更改。 例如，如果我想使用4个空格作为缩进，我可以这样配置：
{
"extends": "stylelint-config-standard",
"rules": {
"indentation": 4
}
}CodeReview 代码审查
代码审查是让其他人审查您的代码的行为。 复习的方式有很多种：比如结对编程（一个人写，一个人读）或者你们在某个时间点互相复习（两个人或者更多人）。
代码审查的目的是检测代码是否符合代码规范以及是否存在错误，同时也让审查者了解被审查者编写的函数。 时不时地互相回顾会让你们双方更清楚地了解整个项目正在做什么，这样你们就不必因为核心开发人员退出而推迟项目。
其实代码审查也有缺点：一是代码审查时间长，二是可能会引起团队成员争吵。 据我了解，目前国外很多开发团队都没有Code Review，包括很多大厂。
我个人建议，在找工作的时候，可以询问一下对方团队是否有测试规范、测试流程、代码评审等，如果你同时具备以上几点，那就说明这是一个靠谱的团队，你可以优先考虑。
git规范
git规范通常包括两点：分支管理规范和gitcommit规范。
分支机构管理规范
通常项目分为主分支（master）和其他分支。
当团队成员想要开发新功能或修复错误时，将从主分支创建一个新分支。 例如，如果项目需要从客户端渲染改为服务端渲染，就会开启一个名为SSR的分支，开发完成后再合并回master分支。
如果你想改一个重大BUG，也可以从master分支上新开一个分支，并用BUG号命名。
# 新建分支并切换到新分支
git checkout -b test
# 切换回主分支，合并新分支
git checkout master
git merge test请注意，当将新分支合并回 master 分支时，如果新分支中有一些不明确的提交，建议先合并它们（使用 gitrebase）。 合并后，将新分支合并回master分支。
gitcommit 规范
git每次提交时，都需要填写commitmessage。
git commit -m 'this is a test'Commitmessage 是对你这次代码提交的简单描述。 好的提交描述可以让人一目了然的明白这次代码提交做了什么。
现在我们了解了commitmessage的重要性css3规范，我们需要更多地了解commitmessage规范。 下面我们看一下commitmessage的格式：
():
我们可以发现commitmessage分为三部分（用空行分隔）：
1.标题行（主题）：需要描述主要变更类型和内容。 2.主题内容（body）：描述为什么要改变，做了什么样的改变，以及开发思路等。 3.页脚（footer）：可以写注释，放一个BUG号的链接。
类型
提交类型：
•feat：新功能、新特性 •fix：改变bug •perf：修改代码以提高性能 •refactor：代码构造（构造，代码更改不影响代码内部行为和功能） •docs：文档更改 •style：代码格式改变，注意不是css改变（如分号改变） •test：测试用例添加、修改 •build：影响项目建立或依赖变化 •revert：恢复上次提交 •ci：持续集成相关文件变更• 杂项：其他变更（不属于上述类型的变更） 发布：发布新版本 工作流程：工作流程相关的文件变更
范围
受commitmessage影响的函数或文件范围，如：route、component、utils、build...
主题
提交消息概述
身体
具体的变化可以分为多行。
页脚
一些评论，通常是 BREAKINGCHANGE 或指向已修复错误的链接。
修复示例（修复BUG）
最好为每个 gitcommit 添加范围描述。
比如这个BUG修复影响整个世界，就可以添加一个全局的。 如果影响某个目录或者某个函数，可以添加该目录的路径，或者对应的函数名。
// 示例1
fix(global):修复checkbox不能复选的问题
// 示例2 下面圆括号里的 common 为通用管理的名称
fix(common): 修复字体过小的BUG，将通用管理下所有页面的默认字体大小修改为 14px
// 示例3
fix(test): value.length -> values.length壮举（添加新功能或页面）
feat: 添加网站主页静态页面
这是一个示例，假设对任务静态页面进行了一些描述。
这里是备注，可以是放 BUG 链接或者一些重要性的东西。杂务（其他变化）
杂务的英文翻译是日常事务、日常工作。 顾名思义，其他提交类型中没有的更改可以用 Chore 来表达。
chore: 将表格中的查看详情改为详情其他类型的提交与前三个示例类似，这里不再赘述。
验证 gitcommit 规范
在 github[8] 的帮助下，当特定的重要操作发生时，可以触发自定义脚本。
验证gitcommit规范也不例外，我们需要通过git的pre-commit钩子函数来完成。 其实你还需要下载一个辅助插件husky来帮你验证。
pre-commit hook 在输入提交信息之前运行，用于检测官方提交快照。
Husky是一个开源工具，使用它我们可以在package.json中配置github脚本。 下面我们看看如何使用它：
下载
npm i -D husky将以下代码添加到package.json：
"husky": {
"hooks": {
"pre-commit": "npm run lint",
"commit-msg": "node script/verify-commit.js",
"pre-push": "npm test"
}
}然后在你的项目根目录下新建一个文件夹script，并在下面新建一个文件verify-commit.js，并输入以下代码：
const msgPath = process.env.HUSKY_GIT_PARAMS
const msg = require('fs')
.readFileSync(msgPath, 'utf-8')
.trim()
// 提前定义好 commit message 的格式，如果不符合格式就退出程序。
const commitRE = /^(feat|fix|docs|style|refactor|perf|test|workflow|build|ci|chore|release|workflow)((.+))?: .{1,50}/
if (!commitRE.test(msg)) {
console.error(`
不合法的 commit 消息格式。
请查看 git commit 提交规范：https://github.com/woai3c/Front-end-articles/blob/master/git%20commit%20style.md
`)
process.exit(1)
}现在我们来解释一下每个钩子的含义：
1. "pre-commit": "npmrunlint"，在gitcommit之前执行npmrunlint检测代码格式。 2. "commit-msg": "nodescript/verify-commit.js"，gitcommit时执行脚本verify-commit.js来验证提交消息。 如果不符合脚本中定义的格式，就会报错。 3. "pre-push": "npmtest"，在执行gitpush将代码推送到远程仓库之前，执行npmtest进行测试。 如果测试失败，则不会执行推送。
通过该工具，我们可以很好的管理团队成员的gitcommit格式，无需花费人力去检测，极大的提高了开发效率。
另外，我提供了一个简单的工程DEMO[9]。 它包括手动低级代码和 git 验证。 如果看完文章后还是不知道如何配置，可以参考一下。
项目规格
项目规范主要是指项目文件的组织形式和命名方法。 统一项目规范的目的是为了方便管理和变更，相同性质的文件不会出现在不同的地方。 例子就像一张图片，一张出现在assets目录下，一张出现在img目录下。
创建目录需要根据用途来定义。 比如比较常见的目录有：文档doc、资源src、测试test...
├─doc
├─src
├─testsrc资源目录可以细分：
├─api
├─asset
├─component
├─style
├─router
├─store
├─util
└─view现在的文件命名方式有很多种（是否缩写imgimage，是否将imgimgs复数，是否使用humpcase，或者如果文件名太长则加入oneTwoone-two）。 虽然使用哪种方法并不重要，但最重要的是命名方法必须统一。
例如，有些团队成员喜欢使用复数（api）来命名目录，有些则喜欢使用偶数（api）。 这是不允许的，必须统一。
用户界面规范
注意，这里的UI规范是指项目中常用的UI组件的表示方式以及组件的命名方式，而不是指如何设计UI组件。
表现形式
现在开源的UI组件库有很多，不同组件库的组件有不同的表现形式。 例如，当点击某些按钮组件时，颜色会变深，而某些组件会变亮。 因此，建议PC端和联通端使用统一的UI组件库（PC端和移动端各使用一个），或者在同一个项目中只使用一个UI组件库。
另外，项目中常用的组件表示也需要通过文档来确定。 例如，动画缩小和扩大的效果是特定于动画的持续时间、动画是慢进快出还是快进慢出等。
如果这种表达形式的规范没有确定，可能会出现以下情况：
1、同一个组件在不同页面有不同的表现（比如动画效果）。 由于没有规范，开发者可以根据个人喜好添加性能效果。 2、同一个二次确认弹窗，提示不同，按键类型也不同。
统一命名
统一命名也是为了降低沟通成本。
举个反例，今天的日期组件可以选择单个日期、日期范围，有的还可以选择时间。 这样，一个日期组件就有四种情况：
1. 带时间的单个日期 2. 无时间的单个日期 3. 带时间的日期范围 4. 无时间的日期范围
如果没有很好的区分这些情况，开发只会在看产品文档时产生怀疑，从而减少开发和产品之间的沟通成本。
总结起来，我们可以发现制定UI规范有两个好处：
1.统一页面UI标准，节省UI设计时间。 2、降低沟通成本，提高后端开发效率。
概括
虽然统一规范最根本的目的是保证团队成员的一致性，从而降低沟通成本，提高开发效率。 我经历过由于规范不标准，导致产品和开发理解出现错误，开发人员自己编写代码，导致各种BUG，最终导致项目延期。
因此，为了提高开发效率，减少加班，请务必规范。
