如果接手别人的项目时，发现代码结构及代码规范写的跟坨便便一样的话，那指不定得问候人家了，看着糟心的代码以及想到后面需要的维护新增，那就是欲哭无泪啊。。。为了尽量少出现这样的情况，可以在书写代码之前或者在写的时候就应该想好代码的设计和规范代码，怎么也要对自己的东西负责，下面是根据自身的实践总结出一小部分，记录下来。

先说一下项目里的格式化配置项

这里我一般比较常用的是 prettier 格式化工具，就 vue 项目来说，用的 vscode 初始化的时候加入一个 .prettierrc 的文件，当然你需要在编辑器里面的下载插件帮助你选择 prettier 格式化操作，然后再里面配置你想要格式化的内容即可，养成随时保存随时格式化的习惯。常用配置项如下：

{
  "tabWidth": 2,  // 给指定每个缩进级别的空格数
  "singleQuote": true,  // 使用单引号而不是双引号
  "semi": false,  // 在语句末尾不打印分号
  "jsxBracketSameLine": true,  // 将 > 多行 JSX 元素放在最后一行的末尾而不是换行
  "trailingComma": "none",  // 多行时不打印尾随逗号
  "bracketSpacing": true,  // 在对象文字中打印括号之间的空格
  "arrowParens": "always"  // 在单个箭头函数参数周围加上括号
}

然后在选择开发工具的保存时自动格式化就OK了，但就这样最基本的常用的项目配置格式化就配好了，当然这些只针对个人开发或者说不需要团队合作，使用这个配置来约束自己的代码质量。然而在公司上得团队从 0 的开发时，这些配置往往都是不够的，比如说，提交的代码没有自动化格式化，提交的时候没有做校验， git 提交时也没有做规范的书写等等。针对这些个问题，我们加强一下自动的配置，具体如下操作：

vscode 安装 prettier

找到 vscode 的扩展插件，然后搜索 prettier 插件安装。

项目中安装 prettier 包管理

在自己的项目的使用 npm 安装 prettier 包 npm install --save-dev --save-exact prettier

项目中创建配置文件

在自己的项目根目录中创建 .prettier 的配置文件，就是上面的配置，拿来就可以直接用了。

创建说明不需要格式化的文件

根据官网的说明，在根目录中也要创建一个忽略的格式化文件。并在其写入：

# Ignore artifacts:
build
coverage

先测试一下格式化是否正常操作

在项目终端输入 npx prettier --write . 查看是否可以正常格式化操作。当然我们肯定不能这样就算配置完成，离自动化的提交总差一点，如果团队有人忘了提交之前格式化的话，那么他提交的代码很有可能是那种乱七八糟的，接下来继续。

配置 gitHook 钩子

lint-staged


在项目终端使用 npx mrm@2 lint-staged 安装提交时自动格式化工具
注意：下载完成之后 package.json 里面有多出如下代码：

"lint-staged": {
  "*.js": "eslint --cache --fix",
  "*.{js,css,md,vue}": "prettier --write"
}

如果是 vue 开发，一定记得写上 vue 扩展，一开始的只有 js,css,md，如果还有 ts 的话也要加上。然后再重新把 package.json 提交。下次如果改动代码之后就会识别，提交时会自动帮助格式化配置文件想要的代码。

加入 commitLint 提交校验

这个工具主要是为帮助我们在提交 git 上可以自主的把提交信息加上，如果不加就会导致 git 提交失败的状况，当然这也是为了团队之后的维护和查看代码，当然如果人其实没多少也就不需要这么多操心了，具体还得看项目大小。
使用起来也是很简单，之间在项目终端中安装对应的包工具即可。

再说项目中的书写规范

如是说 html 和 js 只是开发的时用的骨架和工具，那么 css 的编写技巧可比其要精细的多了，而且在代码规范的考虑中最为重要，说规范之前，首先要思考一下两个问题：

  1. 什么是代码规范？
  2. 为什么需要代码规范？

就如果我上面开篇说的，当我们接手了一个历史悠久的项目代码时，简单的阅读下来，你可以发现里面的变量名都很佛系，什么 abc ，mingzi 这样随意的，或者说是这样 hzxxhwhg 这样带有首拼音的...反正如果没加上注释，完全是看不明白的那种，让人看了一阵头皮发麻，鬼也不知道这是干什么的。

这样的代码命名随意就是一个典型的不规范代码。除了自己或许看了十分钟之后能记起来之外，其他维护的人就完全不知所云了，这样的代码不仅会让下面的人难以维护，也会让其情绪爆炸，口吐芬芳。同时这也极大的降低了团队的协作和效率还有程序的质量。在团队协作中，其他人员如果需要使用这些代码是需要花上很多时间去了解写的是什么意思，修改的稍有不慎就会出现其他的变量名冲突和未知的安全隐患。当然这些只是简单的变量名的例子，在实际项目中远不止这些，变量的命名只是最基础的，不规范的越多，所带来的时间成本就越大。

所以了解了需要规范的由来，就要开始去尝试解决或者说规范自己的书写。

统一规范

上面说的部分出现的场景，在前期的规划代码中就应该提前做好指定代码的规范，针对之前的老代码，如果有需求重构也可慎重，杜绝之前的随意命名。如果在开始的项目开发中不注意命名规范，随意命名，随着项目新增的东西越多，复杂度越来越高，这样不规范的会越来越多，到之后吗难以维护。

随着代码量的积累，针对这样的规范设计可以做以下的协定：

  • 下划线命名： user_name
  • 中划线命名： user-name
  • 小驼峰命名： userName
  • 大驼峰命名： UserName

这样的好处有很多，最直观的就是可以一目了然的知道命名的意思，针对事务命名可以明确主题。但是我们在开发上每个人的习惯是不一样的，在团队开发中有人喜欢用下划线 user_name ，有的则是用小驼峰 userName ，代码上虽然都没有什么问题，但是这样的阅读也会给我们带来一定的不好体验和代码风格的错乱，所以我们需要一个统一的命名。

那么 ESLint 就出现在大家眼前了，在初始化项目的时候通常会有一个选项让其选择格式化工具，这里的就可以选择 ESLint 设置了，在我们书写代码的时候如果出现错误的情况，ESLint 会检查代码的错误并给其提示和优化解，但格式化代码的工具就可以使用我上面写到的 prettier 工具了，针对需要格式的代码我们可以制定自己的方案，在团队协作中发挥重要的作用。

要说这两个有什么相同不同点的话，就是：
相同点：都可以定义一套代码规范。
不同点：ESLint 会在检查时对不规范的代码做出提示；而 prettier 是直接按照你的规范格式化了代码。

所以这两个需要搭配起来用的，最后再加上我们的编辑器 VSCode 上的插件，选择 prettier 格式化就万事大吉了。
最后补充说一下我们常用的命名规范和CSS书写规范，约定一下：

JS

  • 变量命名：下划线 user_id
  • CSS-Class 命名：中划线 user-id
  • 方法函数命名：小驼峰 userId
  • JS-Class 命名：大驼峰 UserId
  • 文件夹命名：中划线 user-id
  • 文件夹下组件命名：中划线 user-id
  • 组件导出命名：大驼峰 UserId

CSS
按顺序书写从上之下开始：

  1. 位置属性 (position, top, right, z-index, display, float 等)
  2. 大小 (width, height, padding, margin 等)
  3. 文字系列 (font, line-height, letter-spacing, color-text-align 等)
  4. 背景 (background, border 等)
  5. 其他 (animation, transition 等)

示例：

.example {  /*  错误示范 × */
  color: red;
  z-index: -1;
  background-color: #9e0;
  display: inline-block;
  font-size: 1.4em;
  padding: 4px 8px;
  position: absolute;
}
.example {  /*  正确示范 √ */
  display: inline-block;
  position: absolute;
  z-index: -1;
  padding: 4px 8px;
  font-size: 1.4em;
  color: red;
  background-color: #9e0;
}

这样的写，第一是可以规范自己代码的养成，第二是代码自身浏览器解析的时候避免不必要的回流和重绘。

以上是本文的全部内容。
只有自己变的强大才是真的强大。

本文部分内容参考链接 前端架构师神技，三招统一代码风格