规则归类

优先级 A：必要的

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

组件名为多个单词

组件的 data 必须是一个函数。

// 在一个 Vue 的根实例上直接使用对象是可以的，

// 因为只存在一个这样的实例。

newVue({

  data: {

    foo: 'bar'

  }

})

prop 的定义应该尽量详细，至少需要指定其类型。

总是用 key 配合 v-for。

永远不要把 v-if 和 v-for 同时用在同一个元素上。

为组件样式设置作用域

私有 property 名

使用模块作用域保持不允许外部访问的函数的私有性。如果无法做到这一点，就始终为插件、混入等不考虑作为对外公共 API 的自定义私有 property 使用 $_ 前缀。

优先级 B：强烈推荐

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

组件文件

只要有能够拼接文件的构建系统，就把每个组件单独分成文件。

单文件组件文件的大小写

单文件组件的文件名应该要么始终是单词大写开头（MyComponent.vue），要么始终是横线连接（my-component.vue）。

基础组件名

单例组件名

紧密耦合的组件名

组件名中的单词顺序

自闭合组件

模板中的组件名大小写

JS/JSX 中的组件名大小写

完整单词的组件名

Prop 名大小写

多个 attribute 的元素

模板中简单的表达式

简单的计算属性

带引号的 attribute 值

指令缩写

优先级 C：推荐

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

[if !supportLists]1.   [endif]训练你的大脑，以便更容易的处理你在社区遇到的代码；

[if !supportLists]2.   [endif]不做修改就可以直接复制粘贴社区的代码示例；

[if !supportLists]3.   [endif]能够经常招聘到和你编码习惯相同的新人，至少跟 Vue 相关的东西是这样的。

组件/实例的选项的顺序

元素 attribute 的顺序

组件/实例选项中的空行

单文件组件的顶级元素的顺序

优先级 D：谨慎使用

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

没有在 v-if/v-else-if/v-else 中使用key

scoped 中的元素选择器

隐性的父子组件通信

非 Flux 的全局状态管理