前言

不知道小伙伴们有没有感觉到，为什么我和别一做一样的开发，经验水平也都差不多，为什么别人的工资就是要比我的高，领导和同喜也都比较喜欢他呢？

确实，当两个人的水平经验都差不多的情况下，有些人写的代码就是要好点，让人看起来很舒服，而且维护起来修改功能人家也比较快。这是什么原因呢，其实就是两个字：规范

好的一个代码习惯，可以起到事半功倍的效果。相反，乱写一气，命名不规范，过段时间自己都不看懂到底是怎么回事，这样的人肯定是不会受老板领导甚至同事的喜欢，以后涨薪也不会优先考虑到你。

下面我们介绍一下关于在Vue开发过程中，一些比较好的规范，让大家都能写出漂亮的代码。

开发工具的选择

相信很多人都喜欢用自己的熟练的开发工具都做开发，这无可厚非，但是当我们来到一个新的公司，同事都用的别的开发工具，而你自己别的开发工具，就拿前端来说吧，有的人喜欢用 vscode，有的喜欢用 webstorm，甚至还有小伙伴喜欢用sublime等一些开发工具。如果是您个人开发的话这是可以的，但现实往往是一个团队一起开发，这样我们就不能根据自己的喜好去选择，而是应该跟着团队一起用一样的开发工具。
一定要记得工具就是为了提高开发效率而来的，切不可一成不变。只有适合的没有好与坏，跟着大家一起才能把事情做好。

vue下的常见开发规范

关于页面或者组件

• 组件名应该始终由多个单词组成，除了根组件 App，以及 <transition>、<component> 之类的 Vue 内置组件。
  比如：Todo，我们应该命名成：TodoItem 或者  todo-item
  不要起单个单词的名字，这样有可能会和html中的标签冲突
  
• 只要有能够拼接文件的构建系统，就把每个组件单独分成文件。对于组件的文件名要么始终是单词大写开头 (PascalCase)，要么始终是横线连接 (kebab-case)。切不可两者混用，
  如：myComponent，应该是 MyComponent 或者 my-component
  个人比较喜欢的是：页面采用kebab-case写法，组件采用PascalCase。这样一眼就可以看出哪个.vue是页面哪个.vue是组件。方便查找
  
• 自闭合的组件使用方式：
  在单文件组件、字符串模板和JSX中应该使用
  

<MyComponet/>

在DOM中应该使用

<my-component></my-component>

关于Props

• 在写的代码中，prop 的定义应该尽量详细，至少指定其类型。
  避免：props: ['status']这样的写法
  要尽可能描述清楚，如：

props: {
  status: {
    type: String,
    required: true,
    validator: value => {
      return [
        'syncing',
        'synced',
        'version-conflict',
        'error'
      ].includes(value)
    }
  }
}

• 在命名变量的时候，要采用camelCase写法，在使用的时候要采用kebab-case写法。看下面的例子：
  

不好的写法

// 定义
props: {
  'greeting-text': String
}
// 使用
<WelcomeMessage greetingText="hi"/>

好的写法

// 定义
props: {
  greetingText: String
}
// 使用
<WelcomeMessage greeting-text="hi"/>

关于v-for的使用

• 在使用v-for的时候，要记住一个不变的规则，就是添加 key 属性。这也是在面试中经常问到的知识。
  

       同时要记得尽量避免 index下标作为key属性的值。尽可能的使用 id

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

    这也是一个常问的面试题，大家一定要知道原理是什么，就是因为 v-if 的优先级要比 v-for 的优先级高，如果在v-if的里面使用v-for的变量，会拿不到该变量，因为还没有执行到v-for。另外也是因为效率的问题，每次循环都要经过一次 if 判断，会影响页面的渲染。

   如果真的要在一起用可以使用下面的方法：

<ul>
  <template v-for="user in users" :key="user.id">
    <li v-if="user.isActive">
      {{ user.name }}
    </li>
  </template>
</ul>

其它方面的规范

• 要为组件样式设置作用域，添加 scoped 属性，避免造成全局的css污染
  
• 组件/实例选项的顺序
  

1. 全局感知 (要求在组件以外被感知)
   

• name
  

2. 模板编译选项 (改变模板编译的方式)
   

• compilerOptions
  

3. 模板依赖 (模板内使用的资源)
   

• components
  
• directives
  

4. 组合 (合并 property 至选项内)
   

• extends
  
• mixins
  
• provide/inject
  

5. 接口 (组件的接口)
   

• inheritAttrs
  
• props
  
• emits
  
• expose
  

6. 组合式 API (使用组合式 API 的入口点)
   

• setup
  

7. 本地状态 (本地的响应式 property)
   

• data
  
• computed
  

8. 事件 (通过响应式事件触发的回调)
   

• beforeCreate
  
• created
  
• beforeMount
  
• mounted
  
• beforeUpdate
  
• updated
  
• activated
  
• deactivated
  
• beforeUnmount
  
• unmounted
  
• errorCaptured
  
• renderTracked
  
• renderTriggered
  
• watch
  
• 生命周期事件 (按照它们被调用的顺序)
  

9. 非响应式的 property (不依赖响应性系统的实例 property)
   

• methods
  

10. 渲染 (组件输出的声明式描述)
    

• template/render


总结

每个公司或者团队在开发规范方面要求不尽相同，以上只是我个人在开发的时候用到的一些规范，不等于其它人或者团队也是这样的要求，我们要做的就是应该尽快适应团队的开发规范。

也可以通过一些工具如：eslint 或者  prettier 等来帮助我们自动格式化代码，这样在写的时候效率也会大大的提高。

最后祝大家都能写出漂亮的代码