前言
随着时间的推移，前端开发越来越复杂，技术栈也是层出不穷，各种工程化，模块化也成了前端开发的必经之路，为了更好的团结协作，开放扩展，后期维护，各司也都有制定独有的开发规范，在这里呢，我就分享一下我司的前端代码开发规范
由于我司主要使用Vue技术栈，所以今天就拿Vue技术栈来说说，主要从以下几个点来分享
- 使用 Ts + eslint 规范
- 项目目录结构
- 组件命名规范
- 路由命名规范
- 事件，方法命名规范
- 变量，常量命名规范
- 注释规范
整体结构范例
my-project-demo // 工程目录
-- node_modules // 依赖文件
-- public // 静态资源入口 index.html
-- src // 核心工作目录
-- assets // 静态资源目录
-- icon
-- imgs
-- less
-- components // 组件目录
-- base-comps // 基础组件目录
-- base-button // 组件目录
-- base-button.less
-- base-button.tsx | .ts
-- BaseButton.vue
-- index.ts // 统一入口处理，格式
-- custom-comps // 业务组件目录
-- todo-list
-- todo-list-item // 紧密耦合组件目录
-- todo-list-item.less
-- todo-list-item.tsx | ts
-- TodoListItem.vue
-- todo-list.less
-- todo-list.tsx | ts
-- Todo-list.vue
--index.ts // 统一入口处理，格式
-- mixins-comps // 统一逻辑处理
-- demo-mixin.ts
-- DemoMixin.vue
-- router // 路由
-- index.ts
-- store // 状态管理
-- index.ts
-- module-a.ts
-- module-b.ts
-- utils // 工具类
-- global.ts
-- views // 主视图目录
-- Home.vue
-- About.vue
-- App.vue // vue核心入口文件
-- main.ts // ts核心入口文件
-- shims-tsx.d.ts // 支持 tsx 配置
-- shims-vue-d.ts // 支持 vue 使用 ts
-- .browserslistrc // 浏览器
-- .eslintrs.js // eslint 规范
-- .gitigonre // git
-- babel.config.js // babel 配置文件
-- package.json // 依赖管理，项目启动与打包命令配置文件
-- REDEME.md // 说明文档
-- tsconfig.json // ts 配置文件
-- vue.config.js // webpack 配置文件
项目目录结构
根据上边的范例，多少可以看出来大概的样子，这里只挑几点描述
- 组件目录一定要细分基础组件和业务组件目录，因为基础组件一般作为工程的基础控件，会被大量使用，会被抽象高度封装，通过不同的配置，达到不同的效果，而业务组件只是在当前项目中需要。参考范例中的
base-comps custom-comps mixins-comps 目录 - 建议每一个目录下，尽量有一个 index.ts 文件，可扩展按需导出，尽管不需要，也建一个空文件，保持工程结构
- 紧密耦合组件一定要呈现树级目录，就近依赖，便于管理和查阅
- 每个组件单独一个目录，拥有自己的样式文件和组件文件，就近依赖，便于后期维护
- Vuex 状态管理如使用较多，尽量区分多个模块，做到区域性管理状态
组件命名规范
- 组件分为基础组件和业务组件
- 组件分为 .vue .tsx .ts 三种形式
基础组件以 base 开头，业务组件则用 custom 开头，意思是自定义业务组件，然后组件又有三种文件的形式，vue 后缀我们一般使用 首字母大写+驼峰形式,而 ts和tsx 后缀的则一律使用小字母，以 - 隔开
例：
compoents
MyButton.vue // vue 后缀，首字母大写+驼峰
base-comps
base-button
base-button.tsx | ts // ts 或者 tsx 后缀
样式文件命名同理
路由命名规范
路由命名采用全小写，单词用 - 隔开格式 因为如果你使用下划线或者驼峰形式，会被当成一个单词，搜索引擎无法区分语义,而 - 隔开会显得更加直观和漂亮
例：
const routes: Array<RouteConfig> = [
{
path: '/',
name: 'Home',
component: Home
},
{
path: '/about-us', // 使用 - 隔开，会被解析为 about 和 us 搜索引擎更容易识别
name: 'About',
component: () => import(/* webpackChunkName: "about" */ '../views/About.vue')
}
]
事件，方法命名规范
这里的事件命名常指通过$emit广播的事件名和监听，而方法则是自定义方法名
-
$emit 事件名一般用
on + "-" + eventName -
自定义方法分为很多种，一般用
handle前缀, 如是一些判断方法，包含方法，获取值，设置值，则分别有自己的前缀，采用前缀+Event时间名，驼峰命名形式 -
handle 大部分自定义方法前缀
-
has 是否包含某值方法前缀
-
is 是否为某个值
-
get 获取某值
-
set 设置某值
例：
// parent 组件
<div @on-emit-evet="handleEmitEvent"
@click="handleClick">
方法触发
</div>
// parent ts 脚本 (方法命名示例)
handleClick (): void {}
handleEmitEvent (arg): void { console.log(arg) }
isPhone (): boolean {return false}
hasLoactionString (): boolean {return false}
getCountValue (): number {return this.count}
setCountValue (n:number): number { this.count = n}
// child 组件
<div @click="handleClickEmit">
事件触发
</div>
// child - ts 脚本
@Emit("on-emit-event")
handleOnEmitEvent():string{
return "参数"
}
这里顺带一下，公共方法命名规范，特别是做工具平台给到二次开发实施用的时候，如何屏蔽公共方法命名冲突，当然解决的方式有很多，封装类，挂载给全局对象对象命名需特殊对待等，都可以，如果是直接定义全局方法，那么需要一定的规范可以来避免这种问题，我是这样做的
自定义唯一值 + Common + 方法名, 驼峰命名方式
这个唯一值，可以讨论自决定，当然符合当前的产品或者跟公司有挂钩的意义还是比较乐观的
例：
function NtCommonThousandth (n: number): number { return n }
变量，常量命名规范
- 变量一般用 let 来声明，驼峰命名格式，语义化
- 常量全用大写字母，下划线隔开
例：
let homeTitle: string = "首页标题"
const MAX_SCREEN_VALUE：number = 1920
注释规范
我常用的注释规范是 jsdoc 规范, 同样也适用于 ts/tsx,，直接用一个例子来体现吧，不太好描述
<script>
// url 声明字段，单行注释
let url = "http://www.baidu.com"
/**
* @编码人 | 时间 | 操作
* 描述
* @return(表示有返回值) {返回类型}
* @param (表示参数描述) {参数类型} | 参数变量名 | 参数描述
**/
/**
* @Hs 2021.11.15
* 获取url值
* @return {string}
**/
function getUrl (): string { return url}
/**
* @Hs 2021.8.15
* 设置url值
* @param {string} u 新的url值
*
* @XXX 2021.11.15 优化 | 新增
* 描述 .... 与上述结构一样
**/
function setUrl (u:string): void {
url = u
}
</script>
大致就是这些，剩下的就是内部编码了，每个人都有自己的编码习惯，当然能约束一下更好，起码按照这样的结构下来，整体效果不会太差，也方便各个同事查阅，维护，代码看起来也会规整很多。ok，今天分享就到这里 。
小小鼓励，大大成长，欢迎点赞收藏
