摸爬滚打这么多年，作为一个十八线前端工程师，对于前端的规范有一些个人的理解。现在打算整理一下，其中一些规范不止适用于前端，但是基本解决方案都是基于前端来完成。前端规范不止包括代码规范，还有git规范等等。

git规范

分支名称规范

master 分支

• master 为主分支，也是用于部署生产环境的分支，确保 master 分支稳定性；
• master 分支一般由 develop 以及 hotfix 分支合并，任何时间都不能直接修改代码；

develop 分支

• develop 为开发分支，始终保持最新完成以及 bug修复后的代码；
• 一般开发的新功能时，feature 分支都是基于 develop 分支下创建的；

feature 分支

• 开发新功能时，以 develop 为基础创建 feature 分支
• 分支命名: feature/ 开头的为特性分支， 命名规则: feature/user-module、 feature/cart-module；

release 分支

• release 为预上线分支，发布提测阶段，会 release 分支代码为基准提测

hotfix 分支

• 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似；
• 线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 hotfix 分支，修复完成后，需要合并到 master 分支和 develop 分支；

提交信息规范

可以引入 commitlint 来督促项目成员有专业化的 commit message 提交。commitlint会用在git的hook回调中，如果不想自己写githooks，那么最简单的就是和 husky一起使用。

目录结构规范

项目组织规范定义了如何组织一个前端项目, 例如项目的命名、项目的文件结构、版本号规范等等。尤其对于开源项目，规范化的项目组织就更重要了。 一个典型的项目组织规范如下:

• README.md: 项目说明, 这个是最重要。你必须在这里提供关于项目的关键信息或者相关信息的入口.
• CHANGELOG.md: 放置每个版本的变动内容, 通常要描述每个版本变更的内容。方便使用者确定应该使用哪个版本. 关于CHANGELOG的规范可以参考keep a changelog
• package.json: 前端项目必须. 描述当前的版本、可用的命令、包名、依赖、环境约束、项目配置等信息.
• .gitignore: 忽略不必要的文件，避免将自动生成的文件提交到版本库
• .gitattributes: git配置，有一些跨平台差异的行为可能需要在这里配置一下，如换行规则
• docs/: 项目的细化文档, 可选.
• examples/: 项目的示例代码，可选.
• build: 项目工具类脚本放置在这里，非必须。如果使用统一构建工具，则没有这个目录
• dist/: 项目构建结果输出目录
• src/: 源代码目录
• tests/: 单元测试目录. 按照Jest规范, __tests__目录通常和被测试的模块在同一个父目录下, 例如:/src tests/ index.ts a.ts index.ts a.ts 复制代码
• tests: 全局的测试目录，通常放应用的集成测试或E2E测试等用例

对于开源项目通常还包括这些目录:

• LICENSE: 说明项目许可
• .github: 开源贡献规范和指南
• CONTRIBUTING: 贡献指南, 这里一般会说明贡献的规范、以及项目的基本组织、架构等信息
• CODE_OF_CONDUCT: 行为准则
• COMMIT_CONVENTION: 提交信息规范，上文已经提及
• ISSUE_TEMPLATE: Issue的模板，github可以自动识别这个模板
• PULL_REQUEST_TEMPLATE: PR模板 上面只是一个通用的项目组织规范，具体源代码如何组织还取决于你们使用的技术栈和团队喜好。下面可以给一些建议。我们从命名原则、根目录、业务逻辑等方面进行目录划分。

1 命名规范

• 简洁明了（如下：）
  • src 源代码
  • img 图片资源 image images
  • js JavaScript脚本
  • dep 第三方依赖包 development package

2 根目录（root）结构按职能划分（如下：）

• src 源代码（逻辑）
• doc 文档
• dep 第三方依赖包
• test 测试

3 根据业务逻辑进行文件夹的划分

• src目录名词解释：
  • common 公共资源
  • public/static 静态资源
  • component 组件
  • view/tpl 模板文件

CSS规范

命名规范

1 BEM规范

BEM的意思就是块（block）、元素（element）、修饰符（modifier）,是由Yandex团队提出的一种前端命名方法论。这种巧妙的命名方法让你的CSS类对其他开发者来说更加透明而且更有意义。

命名约定如下：

.block{} // 块即是通常所说的 Web 应用开发中的组件或模块。每个块在逻辑上和功能上都是相互独立的。

.block__element{} // 元素是块中的组成部分。元素不能离开块来使用。BEM 不推荐在元素中嵌套其他元素。

.block--modifier{} // 修饰符用来定义块或元素的外观和行为。同样的块在应用不同的修饰符之后，会有不同的外观。

OOCSS（面向对象CSS）：

OOCSS 表示的是面向对象 CSS（Object Oriented CSS），是一种把面向对象方法学应用到 CSS 代码组织和管理中的实践。 OOCSS最关键的一点就是：提高他的灵活性和可重用性。这个也是OOCSS最重要的一点。OOCSS主张是通过在基础组件中添加更多的类，从而扩展基础组件的CSS规则，从而使CSS有更好的扩展性。

属性顺序规范

单个样式规则下的属性在书写时，应按功能进行分组，组之间需要有一个空行。 同时要以Positioning Model > Box Model > Typographic > Visual 的顺序书写，提高代码的可读性。

• Positioning Model 布局方式、位置，相关属性包括：position, top, z-index, display, float等
• Box Model 盒模型，相关属性包括：width, height, padding, margin，border,overflow
• Typographic 文本排版，相关属性包括：font, line-height, text-align
• Visual 视觉外观，相关属性包括：color, background, list-style, transform, animation

HTML规范

• 请保证标签语义化，用适当的标签，做相关的事儿；
• 设计好 Dom 层级，避免不需要的多层件套；比如，可以基于伪元素 before、after 来实现一些效果，而不用额外增加一些标签。

JS规范

关于js规范的细节太多，在这里不一一叙述。推荐几个规范：

Airbnb JavaScript Style Guide

号称是“最合理的编写 JavaScript 代码的方式”。 Airbnb 的这个代码规范可能是互联网最流行的 JavaScript 代码规范了，它在 Github 上足有 6 万 star，几乎覆盖了 JavaScript 的每一项特性。

地址：

github.com/airbnb/java…

Google JavaScript Style Guide

只有遵守了这里的规则，一个 JavaScript 源文件才能被称为“Google Style”。很霸气，我行我素，同时也被不少公司沿用。

地址：

google.github.io/styleguide/…

Idiomatic JavaScript Style Guide

符合语言习惯的 JavaScript 代码规范。

不管有多少人参与，不管是否在同一个代码库，所有的 JavaScript 代码风格都必须像同一个人写的。

另一个很强势的同时也很流行的 JavaScript 编码规范。它的野心也很大，不止想规范 JavaScript，其它语言也都想管起来。

地球上所有的代码都像同一个人写的？想想让人觉得不寒而栗啊……

地址：

github.com/rwaldron/id…

JavaScript Standard Style Guide

一个功能强大的 JavaScript 代码规范，自带 linter 和自动代码纠正，无需配置，自动格式化代码。可以在编码早期就发现代码中的低级错误。这个代码规范被很多知名公司所采用，比如 NPM、GitHub、mongoDB 等。

地址：

github.com/standard/st…

（这个 Github 地址霸气到不行。）

VUE文件规范

官网都非常明确的风格指南，可以按照团队需求进行配置。

优先级 A：必要的

这些规则会帮你规避错误，所以学习并接受它们带来的全部代价吧。这里面可能存在例外，但应该非常少，且只有你同时精通 JavaScript 和 Vue 才可以这样做。

优先级 B：强烈推荐

这些规则能够在绝大多数工程中改善可读性和开发体验。即使你违反了，代码还是能照常运行，但例外应该尽可能少且有合理的理由。

优先级 C：推荐

当存在多个同样好的选项，选任意一个都可以确保一致性。在这些规则里，我们描述了每个选项并建议一个默认的选择。也就是说只要保持一致且理由充分，你可以随意在你的代码库中做出不同的选择。请务必给出一个好的理由！通过接受社区的标准，你将会：

训练你的大脑，以便更容易的处理你在社区遇到的代码； 不做修改就可以直接复制粘贴社区的代码示例； 能够经常招聘到和你编码习惯相同的新人，至少跟 Vue 相关的东西是这样的。

优先级 D：谨慎使用

有些 Vue 特性的存在是为了照顾极端情况或帮助老代码的平稳迁移。当被过度使用时，这些特性会让你的代码难于维护甚至变成 bug 的来源。这些规则是为了给有潜在风险的特性敲个警钟，并说明它们什么时候不应该使用以及为什么。

可以用vue-eslint-plugin对优先级 或者优先级里的详细内容进行配置。

代码格式化工具prettier

不管你写的代码是个什么鬼样子，Prettier 会去掉你代码里的所有样式风格，然后用统一固定的格式重新输出。prettier有以下优点：

• 可配置化
• 支持多种语言
• 集成多数的编辑器
• 简洁的配置项

如何使用 Prettier

与 ESLint 结合使用

Prettier 提供了一些与 ESLint 配合使用的工具或插件，刚接触的人可能会比较蒙，不知道这些工具是干什么用的。Stackoverflow 上的 这个回答 解释得比较清楚，这里也简单总结一下：

• prettier-eslint - 一个单独的工具，基本上就是对你的代码先用 prettier 再用 eslint，可以代替 eslint 命令。个人不是很推荐使用。
• eslint-config-prettier - 和一般的 eslint-config-xxx 不同，它不是用来共享 ESlint 配置的，而是用来关闭 ESLint 的样式规则的，避免 ESLint 的样式规则和 Prettier 冲突。使用该配置后，对代码进行 prettier 和 eslint 就不会冲突了。但要注意一定要把它放在 extends 中最后的位置，避免后续的配置又把相关规则打开了。
• eslint-plugin-prettier - 将 Prettier 集成到 ESlint 工作流中，不需要再单独使用 prettier 命令。将 Prettier 发现的代码样式问题当作一条 ESLint 规则，在运行 eslint 检查后显示出来，也同样可以在 --fix 时修复。需要配合 eslint-config-prettier 使用。个人使用了一下基本 OK，但是由于 Prettier 不像 ESLint 那样是单独的一条条规则，因此错误的显示不是很友好。

配合使用

• 配合 husky 和 lint-staged 使用

文档规范

每个项目都应该有一个规范的文档，不同项目要有结构类似的文档统一管理。

以上是我总结的关于前端的规范，希望大家批评指正。