你需要知道的前端代码规范方案

1、为什么需要代码规范？

约束团队成员的编码规范与编码风格

对于一些大型的企业级项目而言，通常情况下我们都是需要一个团队来进行开发的。而又因为团队人员对技术理解上的参差不齐，所以我们需要一套统一的代码规范方案。

代码规范有以下三点好处：

第一：强制规范团队编码，统一新老成员编码习惯
第二：增加项目代码的可维护性与可接入性，新成员能快速适应项目的架构与需求
第三：保障项目整体质量，可减少无用代码、重复代码、错误代码和漏洞代码的产生几率

2、代码格式规范

在部署代码规范之前，我这里强调一下，因为代码规范的前提是约束整个团队的所有项目，所以 代码规范很适合使用一次部署全局运行这样的处理方式。若使用该方案，我们就不需要单独给每个项目都去配置相关文件，这样不仅可以使项目结构变得更加简洁、也节约了项目人员配置的时间成本。

我们这里用的开发工具是vscode，插件用的是stylelint与eslint.

1、安装依赖

因为涉及到的依赖与配置文件太多不好管理，我用了网上一个大神整理的配置文件整合@yangzw/bruce-std，执行下面的安装命令即可，

css 复制代码

npm i -g @yangzw/bruce-std

2、vscode配置

1、在vscode插件市场，搜索并安装Stylelint与Eslint，安装完记得重启VSCode

2、选择文件 → 首选项 →设置，设置中可选用户或工作区
- 用户：配置生效后会作用于全局项目
- 工作区：配置生效后只会作用于当前打开项目
3、点击设置右上角中间图标打开设置(json)，打开的对应文件是settings.json

4、加入以下内容并重启VSCode

json 复制代码

 // 默认自定义配置
	"css.validate": false,
	"less.validate": false,
	"scss.validate": false,
	"editor.codeActionsOnSave": {
        "source.fixAll.eslint": "explicit",
        "source.fixAll.stylelint": "explicit"
    },
	// 扩展自定义配置
	"eslint.nodePath": "/usr/local/lib/node_modules/@yangzw/bruce-std/node_modules",
	"eslint.options": {
    // JS：path/@yangzw/bruce-std/eslint/eslintrc.js
    // TS：path/@yangzw/bruce-std/tslint/tslintrc.js
		"overrideConfigFile": "/usr/local/lib/node_modules/@yangzw/bruce-std/dist/eslintrc.js" 
	},
	"stylelint.configBasedir": "/usr/local/lib/node_modules/@yangzw/bruce-std",
	"stylelint.configFile": "/usr/local/lib/node_modules/@yangzw/bruce-std/dist/stylelintrc.js",
  //CSS/SCSS：postcss-scss
  // CSS/LESS：postcss-less
  // HTML/VUE：postcss-html
	"stylelint.customSyntax": "postcss-scss", 
	"stylelint.stylelintPath": "/usr/local/lib/node_modules/@yangzw/bruce-std/node_modules/stylelint",
	"stylelint.validate": ["html", "css", "scss", "less", "vue"],

上述配置的/usr/local/lib/node_modules/为@yangzw/bruce-std模块所在的npm根目录，
可执行npm config get prefix获取npm根目录。
例如：Mac电脑上是：/usr/local/lib/node_modules/
例如：windows电脑上是：D:/Program Files/nodejs/node_global/node_modules/

3、最后效果

按照上面的步骤全部执行完毕后，例如你以前的代码是这样的：

这时候你只要每次重新保存下代码，vscode就会帮你自动格式化CSS代码与JS代码了，该功能不仅将代码根据规范整理与排序，甚至尽可能根据修复方案格式化出正确的代码，非常的好用。而且这样就无需为每个项目单独配置Lint，使项目结构变得非常简洁。

总结：

有些小伙伴可能一时适应不了ESLint带来的强制性操作，会在编辑器中偷偷关闭项目所有校验功能，这种自私行为不仅让其他成员花费更多时间解决这些额外问题，还浪费了团队的精力。给团队带来不必要的麻烦。所以有一套合适的代码规范是非常重要的。