Vue项目代码规范与最佳实践
该份代码规范适用于基于Vue技术栈的中台项目。
代码规范
Vue组件
javascript
- import文件依次导入顺序为：安装的npm模块，
@路径文件，相对路径文件，不同类型的文件要显式地用空行间隔。示例：
import lodash from 'lodash'
import EnhanceInput from '@/components/enhance-input.vue'
import EhanceSelect from '@/components/enhance-select.vue'
import InsideIcon from './components/inside-icon.vue'
import './style.css'
- import导入时对于非JS类型的文件，需要显式的写入该文件的扩展名。这样做的目的在于在VS Code中配置好该项目的
jsconfig.json文件后，可以友好的进行组件定义跳转。示例：
// good
import EnhanceInput from '@/components/enhance-input.vue'
// bad
import EnhanceInput from '@/components/enhance-input'
- 对于单文件组件，在定义时，需要显式的定义其
name值，这样在使用vue-dev-tool工具时，可以很好的显式整个节点树的信息。为了补充组件的中文描述信息，推荐定义字段cnName。示例：
// good
export default {
name: 'EnhanceInput'，
cnName: '增强的输入框控件'
}
- 对于组件中的
template,javascript,style部分，需要用空行进行间隔。 - 对于页面组件的分页参数，将其存放到当前的页面组件中，而不是对应的store模块中，这样做，方便在是使用
keep-alive特性时，复用页面组件，对分页参数的友好处理。 - 针对第5条提出的操作，在进行页面列表数据请求时，将获取到的列表数据大小返回到当前页面中，并更新对应分页参数的字段的值。
- function code 适当的换行，声明语句，函数调用语句，循环语句之间推荐用空行间隔，这样做的目的是更好的代码可读性。
- 函数名，或者方法名，要命名的有尽量精确，语义化，不要担心长度问题，这是压缩插件应该考虑的事情。
- 变量，函数，函数参数，类的方法/属性使用 Camel 命名法。
- 常量使用 全部字母大写，单词间下划线分割 的命名方式。
Promise对象 用 动宾短语的进行时 表达，示例：
const loadingData = requeset.get('url')
loadingData.then(callback)
- 不要使用3层及以上的解构。过多层次的解构会让代码变得难以阅读。
- 对于深层次（超过3层）嵌套的对象，考虑使用 递归 的手段去处理，而不是硬编码去处理。
- 使用
Object.keys或者Object.entries进行对象遍历，以避免遗漏hasOwnProperty产生的错误，示例：
// good
for (let key of Object.keys(foo)) {
let value = foo[key];
}
// good
for (let [key, value] of Object.entries(foo)) {
// ...
}
- 不要使用jQuery，操作DOM请使用原生语法。
- 在想要抛出
Error以提醒错误的函数调用时，需考虑到开发环境和生产环境的不同，显式地抛出错误要在开发环境处理，而在生产环境应该替换为对用户更为友好的错误提示。具体可查看Vue源码的错误处理代码。
template
- 对于
template部分，在组件的根元素添加对应的class，方便后续写css部分，控制组件内样式的优先级。 - 使用
v-for指令时，使用数组的索引设置数组成员的key值。示例：
<li v-for="(item, idx) in list" :key="idx">{{item}}</li>
Vue官方文档中有写：
你也可以用 of 替代 in 作为分隔符，因为它更接近 JavaScript 迭代器的语法：
所以这里推荐尽量使用of关键字
- 在写模态框相关的代码时，不要使用
v-if来控制模态框的显示，而是通过.sync修饰符来控制属性show，从而控制模态框的显示。
style
- 使用
scoped特性来约束css规则的范围 - 正确使用Display的属性：
a) display:inline后不应该再使用width、height、margin、padding以及float
b) display:inline-block后不应该再使用float
c) display:block后不应该再使用vertical-align
d) display:table-*后不应该再使用margin或者float
项目结构组织
- 对于跨页面使用的业务组件，将其存放到 src/views/index/_components/ 目录下
- 对于基础控件，封装的三方组件，将其存放到 src/components/ 目录下。
- 对于项目用到的
mixin,directive文件，将其统一存放到 src/mixins/ 类似的目录下 - 对于mutation文件中使用的
type变量，将其统一存放到 src/constants/mutation-type.js 文件下，而不是在store中再新建相应的文件 - 开发环境中用于测试，验证原型的Demo文件，将其存放到 src/views/index/_Demo/ 目录下
其他
- 对于接口请求，将其存放到 src/apis/ 目录下，并按项目领域归类，而不是依照store模块进行划分。
最佳实践
代码可读性
- 数组迭代循环选择更好的语义API，示例：
// good
const list = []
// 对于list返回新的数组
const newList = list.map(callback)
// 对数组中每个元素处理
list.forEach(item => {
// doSomething(item)
})
// bad
// 对于list返回新的数组
const newList = []
list.forEach(item => {
newList.push(item)
})
// 对数组中每个元素处理
list.map(item => {
// doSomething(item)
})
- 判断数组类型使用更现代化的API，示例：
// good
Array.isArray(list)
// bad
list instanceof Array
- 数值类型转化使用
Number方法，示例：
const str = '56'
// good
const num = Number(str)
// bad
const num = +str
- 数值取整操作，优先可读性（除非你是在写一个工具库文件），示例：
// good
const n = Math.floor(3.14)
// bad
const n = ~~3.14
V8优化技巧
- 尽量保持函数的功能的单一性
- 不要从未初始化的或已经被删除的元素上加载内容
- 不要写过于庞大的函数，因为他们更难被优化。同样，不要写过于庞大的js文件，在单纯的js文件中，ESLint推荐代码行数保持在350行以下。
注意：当心性能陷阱，过度优化，永远不要过度优化代码，直到你真正需要。现在经常可以看到一些基准测试，显示 N 比 M 在 V8 中更为优化，但是在模块代码或应用中测试一下会发现，这些优化真正的效果比你期望的要小的多。
其他
- 为项目添加单元测试
- 对于复杂的业务流程，或者其他在开发过程中的问题，及时将其产出为实际的文档，将文档存放到 /docs/ 目录下，方便后续对代码的维护。
- 对于全局通用的接口，并且其内容基本不会变化，应做相应的接口数据缓存处理。
- 对于项目入口而言，在 src/index/ 目录下，应该只存在三样文件：main.js,App.vue,router.js
后言
这份规范并不完善，其中某些规定可能因人而异而持不同意见，总之，如果你有更好的想法与建议，请评论到下方。
为什么我们要建立这么一份文档呢？我认为规范的编程可以有效地保证整体代码的可读性，可维护性。并对后续的bug修复更加友好。因此，引出一个问题：对于实现同一个功能的两份代码，一个侧重于可读性，一个侧重于性能。那么，对于可读性和性能，你要如何做两者之间的取舍呢？
4640
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
