vue 项目团队开发代码规范总结
前端项目代码规范
规范目的
统一编码风格，命名规范，注释要求，在团队协作中输出可读性强，易维护，风格一致的代码
统一编码风格
团队协作开发过程中，为了保证代码的可读性，避免因不同的代码编写习惯带来的不必要的编译错误，项目使用ESLint语法规则和代码风格检查工具来保证语法的正确性，统一代码风格。
1、安装 ESLint
npm i eslint -D
如果使用 @vue/cli 脚手架创建项目，创建过程中会有相关的安装提示。
2、.eslintrc.js 配置文件（定义规则）
在项目根目录下新建 .eslintrc.js 配置文件，如果全局安装了 eslint ，可以使用命令初始化该配置文件：
eslint --init
或者是手动新建 .eslintrc.js 配置文件。
3、.eslintignore 忽略文件
在项目根目录创建一个 .eslintignore 文件告诉 ESLint 去忽略特定的文件和目录。如：
build/*.js
src/assets
public
dist
eslint 总是忽略 /node_modules/* 和 /bower_components/* 中的文件
Vue项目中ESLint基本语法要求
- 字符串使用单引号包裹
- 代码结尾不能跟分号
- 声明的变量和方法必须被调用
- tab 键用多个空格代替
- 声明的方法名和圆括号之间加空格
命名规范
命名规范是每个团队都必须面临的问题，用固定的规范可以使得开发的效率得到提升、在交接和维护项目时降低投入的成本。在执行规范的同时，我们应该避免以下的命名现象出现：
- 使用无意义的数字
- 使用英文缩写
- 使用拼音
- 同一项目当中混用多种命名规范
以上的编码习惯无疑会使得代码维护起来的难度加大，在为文件、标识符进行命名的时候应尽量考虑语义化，使下一个开发者能够快速理解它们的含义
目录/文件
常规的文件夹/文件命名使用全小写形式，单词之间使用下划线 _ 连接：src、assets、activity_list
组件文件夹/文件命名使用大驼峰形式（名词）：Coupon、CouponList
Tip: 在Vue、React中我们将页面文件也理解为页面级组件，所以请使用大驼峰的形式命名。
目录结构
├── build # 构建相关
├── public # 静态资源
│ │── favicon.ico # favicon 图标
│ └── index.html # html 模板
├── src # 源代码
│ ├── api # 所有请求
│ ├── assets # 主题、字体等静态资源
│ ├── components # 全局公用组件
│ ├── icons # 项目所有 svg icons
│ ├── layout # 全局 layout
│ ├── router # 路由
│ ├── store # 全局 store 管理
│ ├── styles # 全局样式
│ ├── utils # 全局公用方法
│ ├── views # views 所有页面
│ ├── App.vue # 入口页面
│ ├── main.js # 入口文件 加载组件 初始化等
│ ├── permission.js # 权限管理
│ └── settings.js # 项目基本配置
├── .env.xxx # 环境变量配置
├── .eslintrc.js # eslint 配置项
├── .babelrc # babel-loader 配置
├── .travis.yml # 自动化CI配置
├── vue.config.js # vue-cli 配置
├── postcss.config.js # postcss 配置
└── package.json # package.json
页面文件结构
├── PageName # 页面作为组件使用大驼峰的形式命名
│ │── components # 页面独有组件文件夹
│ └── index.vue # 页面文件
图片
图片需要先为对应的业务性质创建文件夹进行存放，文件夹有效的避免同名文件冲突的问题，文件命名由两部分组成：性质_名称，当某一部分需要使用复合单词时，复合单词之间只用**横杠 - **连接：
- 图标类型： assets/images/icon/icon_tips、assets/images/icon/icon_checked
- 公共类型： assets/images/common/banner_news
- 活动类型： assets/images/activity/banner_news
JavaScript
- 常量命名以全大写形式，单词之间以**下划线 _ **连接：MAX_VALUE
- 标识符(变量、函数)命名使用小驼峰形式：car、carSeries、getUserInfo
- 私有变量命名使用小驼峰形式，单词以**下划线 _ **开头：_time
- 类命名使用大驼峰形式：Person
CSS
样式的命名采用 BEM 规则，何为 BEM 呢？
- B：Block 代表块的意思，可以理解为视觉观感上的一个整体或是功能独立的部件就称为一个块。
- E：Element 代表元素的意思，是被功能独立的块所包裹的元素。
- M：Modifier代表修饰符的意思，它是为了给相同的元素附加属性而存在的。
规则：使用双下划线 __ 连接 B 与 E，用双横杠 – 连接 B 与 M 或 E 与 M，如果某一个部分是复合单词则单词之间以横杠 - 连接，示例如下：
常规单词
.nav
.nav__item
.nav–hover
.nav__item–hover
复合单词
.sub-nav
.sub-nav__item
.sub-nav–hover
.sub-nav__item–hover
常规的修饰符
| 修饰符 | 命名 |
|---|---|
| 激活的 | active |
| 选中的 | selected |
| 默认的 | default |
| 反转的 | toggle |
| 禁用的 | disabled |
| 危险的 | danger |
| 警告的 | warning |
| 错误的 | error |
| 成功的 | success |
| 打开的 | open |
| 关闭的 | close |
| 前一个 | previous |
| 后一个 | next |
| 当 前 | current |
| 信 息 | info |
| 显 示 | show |
| 隐 藏 | hide |
| 大 | lg |
| 小 | sm |
| 特 小 | xs |
常犯的错误
-
BEM 命名的规则讲究的是扁平化，而不是按着 DOM 的层级一直串街命名，所以请不要出现 B__E__E__E 的情况，每个独立的命名永远都是由 B__E–M 三级组成的。
-
块的内部允许存在其他的块（B），不要因为有包含关系就把所有 DOM 认定为元素（E），只要功能完整可以迁移到任何位置我们都可以认为它是一个新的块。包含关系不一定就需要强制应用 B__E 的规则。例如：header 中包含 logo 和 nav，此时 logo 和 nav 就可以单独命名。
注释规范
团队协作开发过程中，为了保证代码的可读性，关键代码处请注释相关的说明。
1、template 结构内容注释
（1）大区块之间需要回车换行，且有单独的中文注释
2、style 注释
（1）每个大区块的样式的需要有单独的中文注释
（2）每个大区块样式之间需要回车换行
（3）在自定义函数库文件中需要对每个语言函数进行单独的批注，或者一些功能类似的语言函数可以根据功能分类注释
3、script 注释
（1）尽可能多用单行注释，注释需要与被注释的地方对齐
（2）生命周期 created()、mounted() 下的所有方法调用需要单独注释，methods 里面涉及接口调用的方法一定要注释，filters 里面的过滤器需要注释说明功能
此规范仅作为参考，如果觉得对你有所帮助，还请点赞支持一下，在此感谢了！