vue前端代码风格开发规范

目录

src 源码目录
|-- api 所有api接口
| |-- approval-manage.js
|-- assets 静态资源，images, icons, styles等
|-- components 公用组件
| |-- SearchBar 公用搜索组件
| |-- |-- index.vue
| |-- |-- index.js
| |-- |-- SearchFormItem.vue
|-- config 配置信息
|-- constants 常量信息，项目所有Enum, 全局常量等
|-- directives 自定义指令
|-- filters 过滤器，全局工具
|-- datas 模拟数据，临时存放
|-- lib 外部引用的插件存放及修改文件
|-- mixins 混入方法文件
|-- mock 模拟接口，临时存放
|-- plugins 插件，全局使用
|-- router 路由，统一管理
|-- store vuex, 统一管理
|-- utils
|-- themes 自定义样式主题
|-- views 视图目录
| |-- role role模块名
| |-- |-- role-list.vue role列表页面
| |-- |-- role-add.vue role新建页面
| |-- |-- role-update.vue role更新页面
| |-- |-- index.less role模块样式
| |-- |-- components role模块通用组件文件夹
| |-- |-- |-- ApprovalDialog.vue role模块通用弹窗组件
| |-- |-- |-- CardTitle.vue role模块通用标题组件
| |-- approval-management approval-management模块

文件夹命名

components中的组件文件夹使用PascalCase命名， 组件文件名也是为PascalCase 格式（index.js和index.vue除外）
其他文件夹以kebab-case方式命名
其他文件命名方式以kebab-case方式命名

变量命名

常量命名规范为KEBAB_CASE

类名，id命名方式

css命名参考BEM命名规范，BEM的意思就是块（block）、元素（element）、修饰符（modifier）,是由Yandex团队提出的一种前端命名方法论。这种巧妙的命名方法让你的CSS类对其他开发者来说更加透明而且更有意义。BEM命名约定更加严格，而且包含更多的信息，它们用于一个团队开发一个耗时的大项目。
BEM参考链接

.block 代表了更高级别的抽象或组件。
.block__element 代表.block的后代，用于形成一个完整的.block的整体。
.block–modifier代表.block的不同状态或不同版本。

.site{} /* 块 */  
.site-search{} /* 元素 */  
.site-search__field{}/*子 元素 */ 
.site-search--full{}/* 修饰符 */

有的小伙伴可能会觉着，类名命名不同又不影响什么，写在代码里面的，不影响目录结构，这个又不会相互影响，而且每个人写代码风格有自己的风格，这种命名方式看起来不好看，不好复制，但是如果你在一个项目中遇到了以下几种命名，甚至是在一个vue文件下面遇到两个或者两个以上的命名方式：
siteSearch
siteSearch2
sitesearch
chaxun
site-search
site_search
__site-search
一个团队协作完成一个项目，为什么不能保证风格统一呢，一个项目，保证别人在阅读的时候，感受出来的是一种风格，这难道不是更难得的吗，就会觉得，有一个统一的命名真好。

方法命名

方法命名方式为小驼峰方式

注释

文本注释

<!-- XX模块注释 -->

变量为单行注释

 //单行注释

方法注释为多行注释

/**
 * @description  
 * @param 
 * @return 
 * @author
 * */

以下情况，务必添加注释:

    公共组件使用说明
    各组件中重要函数或者类说明
    复杂的业务逻辑处理说明
    特殊情况的代码处理说明,对于代码中特殊用途的变量、存在临界值、函数中使用的hack、使用了某种算法或思路等需要进行注释描述
    多重 if 判断语句

可以从以下代码片段看出注释的重要性。

很明显，在两者代码片段的对比下，左侧无注释的代码阅读难度比右边的阅读难度高很多。
不知道大家有没有体验过，自己写代码，在时隔一个月之后重读，居然第一时间是问，‘这是谁写的代码，为什么没写注释，’或者‘这个注释写得啥都看不懂，字是字，代码是代码，’。而不记得写代码时自己说过的，‘这段代码逻辑这么简单，不用写注释’或者‘我写了一些简单的注释的，很容易理解的嘛。’
有些简单的代码在业务场景的加持之下，代码理解的成本是加倍的。
当初不写注释的自信，现在读不懂代码的时候更是想花一点时间。
所以为了后面代码被其他人接手时的友好体验，尽可能将注释补全，避免耗费过多的代码熟悉成本，而且在后期再去补全注释的难度比在开发期间写全注释的难度要大很多（至于说写中文注释还是写英文注释，这个根据个人能力和团队能力来决定）。但是如果你说确实开发期间的排期太紧张了，没时间来写这些注释，那我建议至少在提测期间，也至少得补全，不要说着后面来补然后遥遥无期，等着下一个接手的人来看一眼这个代码就要窒息的感觉。
一个栗子
说一个作者自身的例子，在作者呆的一家公司，刚入职的时候小菜鸟一个，因为比较熟悉原生写法，所以虽然对于vue不熟悉，但是被当时的前端老大破格招入。当时公司内部使用的一套后台框架正是这个前端老大和之前的另外一个大佬使用vue写的。
进来之后，大佬离职，由于多数人反馈，框架组件文档缺失严重，作者开始维护这套框架里面的组件文档和扩展组件部分功能，入职还不到一个月的时候，框架出现了内存泄露问题。
虽然问题暴露目前只出现在一个某M子应用加载出来时框架才有内存泄露问题，但由于M子应用是公司内部线下团队使用作业的主要应用而且公司百来个子应用都接入在此框架中，如不排查问题，不知道其他哪些子应用加载的时候还会触发此问题，涉及范围较广，所以在问题出来之后，公司及其重视此问题，定了一周的时间，公司专门让前端老大成立了一个专项组来解决这个问题，但是由于其他同事手上都还有原本的项目，所以就由我和另外一个同事着重来处理这件时间。
我们一起把框架的代码反复看，尤其对里面满屏的代码，寥寥几行的注释看得头疼。初看觉得对此代码充满的敬畏，写者能力高深，害怕自己看不懂（求助前作者，都说，之前写得太匆忙，只能记得是为了实现什么功能，但是其他详细的也不记得了。）；每看一段代码，上下关联极多，甚者可以跨越山和大海，关联好几个其他文件内容。反复阅读数天之后，每天都在寻求公司其他部门大佬的支持，还私下问了很多其他的小伙伴。每天的周报都是写的，问题可能是由什么原因导致的，今天尝试了什么方法，结果是什么，明天准备怎么排查。却还是没有找到内存溢出的根本原因在哪里。后来虽然在给定的时间期限内最后一天的下午把问题排查出来并及时解决处理，后续持续跟进了一段时间反馈也无复现问题，但此次经历对读者印象极深。
在处理这件事情的整个过程中，我们最难受的不是代码看不懂，而是看不懂上下关联，代码一块一块的都是可以看懂，但是糅合在一起之后，跳来跳去之后，思绪一点都不丝滑。而且这样会体现一个问题，每当出现一个这样的项目时，几乎所有的人都是避之不恐的，生怕自己会变成这个项目的继承人，甚至原作者都会对这个项目开始有些躲避，因为时间一长，以前匆忙之下写下的一些明知有坑的地方，可能现在就忘记在哪里了。。。
项目无人敢接手，一旦接手又很难交接给别人，所有人只要涉及这个项目的改动，都需要找你来改，找别人做都会推脱说这个项目太难了，代码复杂，涉及范围太广了，之前都是XX负责的。明明自己也是半路接手的人，而作者在刚入职之后就接手了两个这样的项目，泪目。

style

关于样式问题，有几点建议
1，不使用行内样式
2，项目基础颜色存变量值，定义一个公共基础样式
3，使用scope实现样式隔离
关于行内样式，优先级最高，后期维护很难改动。
项目中颜色值是很常用的，而且一般会有一组基础值，定义一组变量值，后期颜色需要更换时，只需要改一次就可以改完整个项目中的所有颜色。

为什么前端规范的问题一直在各个公司都是绕不开的话题，规范为什么如此重要呢？
我能把代码跑起来，项目启起来，不就完成这个项目了吗？
别人看不懂我的代码，不是证明我的能力很高？
为什么我要别人看懂我的代码，我的代码是给机器阅读的，机器也要读我的注释才能运行我的代码吗？
我自己写的代码，我写什么注释，我不知道自己写的代码怎么运行的吗？
以上这些想法，会让你成为这个项目不可或缺的重要人员，因为其他人的维护成本和熟悉成本太大。但是一个公司是需要一个只能一个人维护的项目，还是需要一个任何一个人都可以维护的项目？
一个不规范的项目，最终的走向要么是重构，要么是最后的弃用。因为项目越来越大之后，维护成本会越来越大，新人接手的熟悉成本也越来越大。
只要大家要求代码的风格有统一要求，也不一定如作者文中介绍的这些规范要求。
在推广代码风格开发规范时，宣导是一方面，还有一方面是需要按照宣导去验收。从业几年的前端同事大多都有自己的一些习惯，有时候这些习惯是和你所宣导的规范是相冲突的，所以可能在他自身不经意的情况下一些代码没有遵守规范，我们需要发现这些问题，前期多进行提醒，后期他们潜意识的书写规范已经被规范过来了，就可以不用像前期那样时时提醒了。