同在一起做一样的开发，为什么别人的工资就是高呢？这份规范指南建议收藏

01

前言

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

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

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

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

02

开发工具的选择

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

03

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> <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

04

总结

每个公司或者团队在开发规范方面要求不尽相同，以上只是我个人在开发的时候用到的一些规范，不等于其它人或者团队也是这样的要求，我们要做的就是应该尽快适应团队的开发规范。 也可以通过一些工具如：eslint 或者 prettier 等来帮助我们自动格式化代码，这样在写的时候效率也会大大的提高。 最后祝大家都能写出漂亮的代码