一、目录结构
||— build 构建脚本目录
|— build.js 生产环境构建（编译打包）脚本
|— check-versions.js 版本验证工具
|— utils.js 构建相关工具方法（主要用来处理css类文件的loader）
|— vue-loader.conf.js 处理vue中的样式
|— webpack.base.conf.js webpack基础配置
|— webpack.dev.conf.js webpack开发环境配置
|— webapck.prod.conf.js webpack生产环境配置
|— config 项目配置
|— dev.env.js 开发环境变量
|— index.js 主配置文件
|— prod.env.js 生产环境变量
|— test.env.js 测试环境变量
|— node_modules 项目依赖模块
|— src
|— assets 资源目录，资源会被webpack构建
|— components
|— base-components
|— func-components
|— page-components
|— element-ui
|— libs
|— mixins
|— pages
|— router
|— store
|— static 纯静态资源，不会被webpack构建，eg:没有npm包模块
|— .babelrc babel的配置文件
|— .editorconfig 编辑器的配置文件
|— .gitignore git的忽略配置文件
|— .postcssrc.js postcss的配置文件
|— index.html html模板，入口页面
|— package.json npm包配置文件，依赖包信息
|— README.md 项目介绍
二、UI框架选择
1.PC端Vue项目UI框架优先选择：Element UI（优先）
2.移动端Vue项目UI框架：vant-ui（优先）
三、CSS预处理器选择
1.sass
四、命名规范
1.文件夹
命名方法 ：小写开头，驼峰命名法
命名规范 ：命名必须是跟需求的内容相关的词（尽量是名词）
其余文件夹名称统一按照项目结构目录命名规范统一命名。
home
homeEdit
user
2.组件
- 基础组件
命名方法 ： lyl -驼峰命名法
当项目中需要自定义比较多的基础组件的时候，比如一些select，input，icon，datapicker，且放到src->components->base-components文件夹统一管理，这样做的目的是为了方便查找。
lyl-input
lyl-select
lyl-datePicker
- 功能组件
命名方法 ： lyl -驼峰命名法
当项目中需要用到功能性（自定义/第三方插件）的组件时，不如目前的动态验证码，密码强度组件等，建议以一个统一的单词 lyl -驼峰命名法，且放到src->components->func-components文件夹统一管理，这样做的目的是为了方便查
找。
- 页面组件
命名方法 ：驼峰命名法
命名规范 ：命名必须是跟需求的内容相关的词
必要时先见文件夹，放页面有共性的组件，命名规则为需求内容相关词 ，，尽量不要用到业务逻辑数据，以props值传入。
若一些组件只有这个页面用到，其他地方没有用到的，可以直接放到页面文件夹，然后以父组件开头命名
home-test
home-datePicker
3.普通变量命名规范
命名方法 ：驼峰命名法
命名规范 ：命名必须是跟需求的内容相关的词，如
let productPageDetail = "产品详情页面";
命名是复数的时候需要加s,如
let items= new Array();
let productList = new Array();
4.常量
命名方法 : 全部大写
命名规范 : 使用大写字母匈牙利式命名法。
const MAX_COUNT = 10
const URL = 'https://www.cupshe.com/'
5.method 方法命名命名规范
驼峰式命名，统一使用动词或者动词+名词形式
getUserList,
submitCartProduct
请求数据方法，以 data 结尾
getProductListData
getUserData
6.props 命名
在声明 prop 的时候，使用驼峰命名法，在模板中使用 kebab-case
<script>
props: {
greetingText: {
....
}
}
</script>
<welcome-message greeting-text="hi"></welcome-message>
五、vue 文件基本结构
结构遵循从上往下template，script，style的结构
1.script
- components
- mixins
- props
- filter
- data
- computed
- watch
- created
- mounted
- metods
2.style里一定需要申明语言，并且添加scoped
<template>
<div>
...
</div>
</template>
<script>
export default {
name:"",
components:{},
mixins:[],
data () {
return {
...
}
},
watch:{
...
},
computed:{
...
},
created() {
...
}，
methods: {
...
}
}
</script>
<!--声明语言，并且添加scoped-->
<style lang="scss" scoped>
</style>
六、编码规范
1.指令规范
:class="{'avtive'：true}"
@click="getListData"
2.v-for 循环必须加上 key 属性，在整个 for 循环中 key 需要唯一
<ul>
<li v-for="todo in todos" :key="todo.id">
{{ todo.text }}
</li>
</ul>
<tempate v-for="todo in todos">
{{todo}}
</tempate>
3.避免 v-if 和 v-for 同时用在一个元素上（性能问题）
- 将数据替换为一个计算属性，让其返回过滤后的列表
<ul>
<li v-for="user in activeUsers" :key="user.id">
{{ user.name }}
</li>
</ul>
<script>
computed: {
activeUsers: function () {
return this.users.filter(function (user) {
return user.isActive
})
}
}
</script>
- 将 v-if 移动至容器元素上 (比如 ul, ol)
<ul v-if="shouldShowUsers">
<li v-for="user in users" :key="user.id">
{{ user.name }}
</li>
</ul>
4.Props 规范
// bad 这样做只有开发原型系统时可以接受
props: ['status']
// good
props: {
status: {
type: String,
required: true,
validator: function (value) {
return [
'syncing',
'synced',
'version-conflict',
'error'
].indexOf(value) !== -1
}
}
}
七、注释规范
代码注释在一个项目的后期维护中显的尤为重要，所以我们要为每一个被复用的组件编写组件使用说明，为组件中每一个方法编写方法说明
务必添加注释列表
- 公共组件使用说明
- 各组件中重要函数或者类说明
- 复杂的业务逻辑处理说明
- 特殊情况的代码处理说明,对于代码中特殊用途的变量、存在临界值、函数中使用的 hack、使用了某种算法或思路等需要进行注释描述
- 多重 if 判断语句
- 注释块必须以/（至少两个星号）开头/
- 单行注释使用//
单行注释
注释单独一行，不要在代码后的同一行内加注释。例如：
// bad
var name =”abc”; // 姓名
// good
// 姓名
var name = “abc”;
多行注释
组件使用说明，和调用说明
/**
* 组件名称
* @module 组件存放位置
* @desc 组件描述
* @author 组件作者
* @date 2017年12月05日17:22:43
* @param {Object} [title] - 参数说明
* @param {String} [columns] - 参数说明
* @example 调用示例
* <hbTable :title="title" :columns="columns" :tableData="tableData"></hbTable>
**/
八、其他
避免 this.$parent调试信息
console.log() debugger 使用完及时删除
除了三目运算，if,else 等禁止简写
// bad
if (true)
alert(name);
console.log(name);
// bad
if (true)
alert(name);
console.log(name)
// good
if (true) {
alert(name);
}
console.log(name);
九、CSS 规范
统一使用"-"连字符
省略值为 0 时的单位
如果 CSS 可以做到，就不要使用 JS
建议并适当缩写值，提高可读性，特殊情况除外
padding-bottom: 0;
margin: 0;
如果 CSS 可以做到，就不要使用 JS
建议并适当缩写值，提高可读性，特殊情况除外
“建议并适当”是因为缩写总是会包含一系列的值，而有时候我们并不希望设置某一值，反而造成了麻烦，那么这时候你可以不缩写，而是分开写。
当然，在一切可以缩写的情况下，请务必缩写，它最大的好处就是节省了字节，便于维护，并使阅读更加一目了然。
// bad
.box{
border-top-style: none;
font-family: palatino, georgia, serif;
font-size: 100%;
line-height: 1.6;
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;
}
// good
.box{
border-top: 0;
font: 100%/1.6 palatino, georgia, serif;
padding: 0 1em 2em;
}
