在大多数项目中，这些规则被发现可以提高可读性和/或开发人员体验。如果你违反了它们，你的代码仍然会运行，但违规应该是罕见的，而且有充分的理由。
组件文件
每当构建系统可用于连接文件时，每个组件都应位于其自己的文件中。
这有助于您在需要编辑组件或查看如何使用组件时更快地找到组件。
//坏
app.component('TodoList', {
// ...
})
app.component('TodoItem', {
// ...
})
//好
components/
|- TodoList.js
|- TodoItem.js
//或者
components/
|- TodoList.vue
|- TodoItem.vue
单文件组件文件名大小写
单文件组件 应始终为 PascalCase 或始终为 kebab-case。
PascalCase 最适合代码编辑器中的自动完成，因为它与我们在 JS（X） 和模板中引用组件的方式一致。但是，混合大小写的文件名有时会在不区分大小写的文件系统上产生问题，这就是为什么 kebab-case 也是完全可以接受的。
//坏
components/
|- mycomponent.vue
//或者
components/
|- myComponent.vue
//好
components/
|- MyComponent.vue
//或者
components/
|- my-component.vue
基本组件名称
应用特定于应用的样式和约定的基本组件（也称为表示性组件、哑组件或纯组件）都应以特定前缀开头，例如 Base、 App或 V。
//坏
components/
|- MyButton.vue
|- VueTable.vue
|- Icon.vue
//好
components/
|- BaseButton.vue
|- BaseTable.vue
|- BaseIcon.vue
//或者
components/
|- AppButton.vue
|- AppTable.vue
|- AppIcon.vue
//或者
components/
|- VButton.vue
|- VTable.vue
|- VIcon.vue
紧密耦合的组件名称
与其父组件紧密耦合的子组件应包含父组件名称作为前缀
如果组件仅在单个父组件的上下文中才有意义，则该关系应在其名称中显而易见。由于编辑器通常按字母顺序组织文件，因此这也使这些相关文件彼此相邻。
//坏
components/
|- TodoList.vue
|- TodoItem.vue
|- TodoButton.vue
//或者
components/
|- SearchSidebar.vue
|- NavigationForSearchSidebar.vue
//好
components/
|- TodoList.vue
|- TodoListItem.vue
|- TodoListItemButton.vue
//或者
components/
|- SearchSidebar.vue
|- SearchSidebarNavigation.vue
组件名称
组件名称应以最高级别（通常是最通用）的单词开头，并以描述性修饰单词结尾。
比如我们要形容一个好看的女孩子，在中国一般都是说：很好看的女孩子，修饰的名字放在后面，而用英语来说的话the gird is beautiful，名词在前面，对于组件命名也是这样的。把最重要的名词放在命名前面，可以一目了然。
//坏
components/
|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vue
//好
components/
|- SearchButtonClear.vue
|- SearchButtonRun.vue
|- SearchInputQuery.vue
|- SearchInputExcludeGlob.vue
|- SettingsCheckboxTerms.vue
|- SettingsCheckboxLaunchOnStartup.vue
自闭组件
没有内容 的组件应该在单文件组件 、字符串模板和 JSX 中自关闭，但在 DOM 模板中永远不要。
自关闭的组件传达出它们不仅没有内容，而且 意味着 没有内容。这是一本书中的空白页和标有“此页故意留空”的空白页之间的区别。 您的代码也更简洁，没有不必要的结束标记。
不幸的是，HTML 不允许自定义元素是自闭合的——只允许官方的 “void”元素 。这就是为什么只有当 Vue 的模板编译器可以在 DOM 之前到达模板，然后提供符合 DOM 规范的 HTML 时，该策略才有可能。
//坏
<!-- In Single-File Components, string templates, and JSX -->
<MyComponent></MyComponent>
<!-- In in-DOM templates -->
<my-component/>
//好
<!-- In Single-File Components, string templates, and JSX -->
<MyComponent/>
<!-- In in-DOM templates -->
<my-component></my-component>
模板中的组件名称大小写
和字符串模板中应始终为 PascalCase 在大多数项目中，组件名称在单文件组件 ，但在 DOM 模板中应为 kebab-case。
与烤肉串相比，PascalCase 有几个优点：
- 编辑器可以在模板中自动完成组件名称，因为 JavaScript 中也使用了 PascalCase。
- 在视觉上与单字 HTML 元素相比 ，因为有两个字符差异（两个大写字母），而不仅仅是一个字符差异（连字符）。
- 如果你在模板中使用任何非 Vue 自定义元素，比如 Web 组件，PascalCase 会确保你的 Vue 组件保持清晰可见。
不幸的是，由于 HTML 不区分大小写，DOM 模板仍然必须使用 kebab-case。
另请注意，如果您已经在 kebab-case 上投入了大量资金，那么与 HTML 约定的一致性以及能够在所有项目中使用相同的大小写可能比上面列出的优势更重要。在这些情况下， 到处使用烤肉串也是可以接受的。
//坏
<!-- In Single-File Components and string templates -->
<mycomponent/>
<!-- In Single-File Components and string templates -->
<myComponent/>
<!-- In in-DOM templates -->
<MyComponent></MyComponent>
//好
<!-- In Single-File Components and string templates -->
<MyComponent/>
<!-- In in-DOM templates -->
<my-component></my-component>
<!-- Everywhere -->
<my-component></my-component>
全字组件名称
组件名称应优先使用完整单词而不是缩写。
编辑器中的自动补全功能使编写较长名称的成本非常低，而它们提供的清晰度是无价的。特别是，应始终避免使用不常见的缩写。
//坏
components/
|- SdSettings.vue
|- UProfOpts.vue
//好
components/
|- StudentDashboardSettings.vue
|- UserProfileOptions.vue
defineProps名称大小写
在声明期间，道具名称应始终使用 camelCase。在 DOM 模板中使用时，props 应该是烤肉串大小写的。单文件组件模板和 JSX 可以使用 kebab-case 或 camelCase 道具。外壳应保持一致 - 如果您选择使用骆驼壳式道具，请确保在应用程序中不使用烤肉串式道具
//坏
const props = defineProps({
'greeting-text': String
})
//坏
// for in-DOM templates
<welcome-message greetingText="hi"></welcome-message>
//好
const props = defineProps({
greetingText: String
})
//好
// for SFC - please make sure your casing is consistent throughout the project
// you can use either convention but we don't recommend mixing two different casing styles
<WelcomeMessage greeting-text="hi"/>
// or
<WelcomeMessage greetingText="hi"/>
//好
// for in-DOM templates
<welcome-message greeting-text="hi"></welcome-message>
模板中的简单表达式
组件模板应仅包含简单的表达式，并将更复杂的表达式重构为计算属性或方法。
模板中的复杂表达式会降低其声明性。我们应该努力描述 what 应该出现什么，而不是 我们如何 计算该值。计算的属性和方法还允许重用代码。
//坏
{{
fullName.split(' ').map((word) => {
return word[0].toUpperCase() + word.slice(1)
}).join(' ')
}}
//好
<!-- In a template -->
{{ normalizedFullName }}
//好
// The complex expression has been moved to a computed property
const normalizedFullName = computed(() =>
fullName.value
.split(' ')
.map((word) => word[0].toUpperCase() + word.slice(1))
.join(' ')
)
简单的计算属性
复杂的计算属性应拆分为尽可能多的简单属性。
简单来说有三点好处
- 更易于测试
- 更易于阅读
- 更能适应不断变化的需求
//坏
const price = computed(() => {
const basePrice = manufactureCost.value / (1 - profitMargin.value)
return basePrice - basePrice * (discountPercent.value || 0)
})
//好
const basePrice = computed(
() => manufactureCost.value / (1 - profitMargin.value)
)
const discount = computed(
() => basePrice.value * (discountPercent.value || 0)
)
const finalPrice = computed(() => basePrice.value - discount.value)
