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

2022-10-28 18:58:55 浏览数 (1)

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']这样的写法 要尽可能描述清楚,如:
代码语言:javascript复制

props: {
  status: {
    type: String,
    required: true,

    validator: value => {
      return [
        'syncing',
        'synced',
        'version-conflict',
        'error'
      ].includes(value)
    }
  }
}
  • 在命名变量的时候,要采用camelCase写法,在使用的时候要采用kebab-case写法。看下面的例子:

不好的写法

代码语言:javascript复制
// 定义
props: {
  'greeting-text': String
}
// 使用
<WelcomeMessage greetingText="hi"/>

好的写法

代码语言:javascript复制
// 定义
props: {
  greetingText: String
}
// 使用
<WelcomeMessage greeting-text="hi"/>

关于v-for的使用

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

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

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

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

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

代码语言:javascript复制
<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 等来帮助我们自动格式化代码,这样在写的时候效率也会大大的提高。 最后祝大家都能写出漂亮的代码

0 人点赞