前端书写代码规范

本规范目的在于约定项目内研发，期望覆盖的流程包括 codeStyle、commit规范、MR规范、发版规则。

CodeStyle

CSS

强制：css 禁用 !import

推荐: 不使用style。都抽象成class

强制：z-index取值范围为 [0, 20]

强制：class名用短横线分割,如：side-menu 、 submit-deploy-btn

JS

强制：禁用any

强制：禁用 watch，除非处理“副作用”。如果使用需要注释说明原因。副作用解释WIKI

强制：computed内不设置外部值，包括外部ref、reactive、url参数

推荐：不使用localStora和sessionStorage进行参数传递。如果使用需要注释说明

推荐：禁用stringify和parse大部分情况禁用。

强制：禁用with

强制：禁用Function

强制：禁用eval

强制：禁用innerHTML及类似function

强制：禁用 == , 只使用 ===

推荐：不使用deepCopy等相关函数。

强制：禁止使用setInterval，推荐使用setTimeout实现功能

推荐：不添加不必要的setTimeout

强制：不使用nextTicket

推荐: 建议合理使用 `?`运算符。如 item?.name，需要确定在返回undefined的时候不会有问题

风格

推荐：符号前后添加空格。现有的Lint已经失效

标识符命名

强制: 变量命名使用小驼峰命名

强制: 函数命名使用小驼峰命名

强制: 常量命名使用大写, 如有多个单词，用下划线隔开

强制: 类命名使用大驼峰命名

强制: interface 命名推荐使用大驼峰命名，并携带前缀I

强制: type 命名推荐使用大驼峰命名, 最后添加Type

强制: 枚举命名推荐使用大驼峰命名，最后添加Enum

推荐: ref 变量命名，推荐用 xxxRef

文件命名

强制: 单文件组件(页面)命名使用大驼峰命名，模板统一使用大驼峰方式，文件夹使用小写加短横线方式

强制: 工具函数文件命名使用小驼峰命名

强制: 资源文件命名使用小驼峰命名

函数定义

推荐: 函数定义方式推荐使用函数表达式

强制：hooks的定义使用use开头

路由及Query参数定义

强制: Url中query定义使用小写，如有多个单词，用下划线隔开

强制: 路由query定义使用小写，如有多个单词，用下划线隔开

强制: 路由params使用小驼峰声明

模块导入导出

推荐: 本项目支持src别名, 模块导入时过长推荐使用 ~ 别名

推荐: 模块导出时，尽量使用具名导出

请求处理

推荐: 请求处理时，推荐使用async/await

推荐: 推荐在onMounted钩子中进行接口请求

推荐：暂不使用suspense

代码抽离重构

推荐: 单文件组件的模板中，插值依赖变量过多，建议抽离成computed；若在v-for中的插值，可抽离成函数；

推荐：不使用tsx，table自便；

推荐: 单文件组件中，公用的方法建议抽离成composable函数或者工具函数；单文件强制非样式最大 500 行

其他

强制: 所有代码编写使用typescript语法

推荐: 单文件组件推荐使用 setup script

commit规范

由formula-cli初始化的项目，会生成默认的pre-commit，要求开发者在进行迭代时 保证commit信息的规范，否则会被拦截，无法进行提交。

<类型>[(范围)]:<空格><主题,单行>

<BLANK LINE>

[描述,多行,可选]

<BLANK LINE>

[附录,多行,可选]

类型:

# feat: 引入了新的特性或功能

# fix: 修复了某个bug

# revert: 回滚某个提交，主题中请明确commit hash

# improvement: 代码结构改进、性能优化，不涉及新功能或bug修复

# dep: 升级或添加相关依赖

# ci: 构建脚本或配置更新

# style: 代码风格更新

# test: 测试代码更新

# docs: 文档方面更新

范围：

作为可选项，位于类型之后，使用英文圆括号`()`标注，用于明确当前提交作用范围。

明确的范围可以帮助代码审核者快速判断当前提交的影响范围并提高审核效率。 示例：`feat(note detail): 支持新版笔详的样式设计`

描述：

添加提交的详细描述，例如主要做了哪些层面的具体改动。如涉及重大修改，请在描述中利用'BREAKING CHANGE'标识，以便CI等工具进行相应处理。 示例: `BREAKING CHANGE: 修改了note中title字段类型（Object -> String）`

附录: 列举关联的 issue 或 MR 信息，便于记录和追踪完整上下文。

示例: close #1, fixed #2, also check cube-image#3, related to !4。

Conventional Commits

Git设置规范

user.name = [个人性命中文 | 个人性命拼音]

user.email = 工作邮箱

✅ GOOD:

user.name="enning" user.email=lilijing@hongshu.com

user.email=lilijing@hongshu.net

❌ BAD:

user.name="xiaobai"

user.email="lilijing@gmail.com"

MR规范

分支规范

feature-xxx：功能开发分支，开发者从 master 上拉出新分支，以自己开发功能模块命名，功能测试正常后开发者提交 MR 到即将发布的release分支，由项目/功能相关同学 CR。

hotfix-xxx：紧急bug修改分支，项目上线之后可以会遇到一些环境问题需要紧急修复，在master创建，修复完成后提 PR 到 master 分支，由Owner/Backup 操作后触发 tag，功能开发者走后续 CD 流程。

注意事项： 一个分支尽量开发一个功能模块，不要多个功能模块在一个分支上开发。

多人合作开发需求，泳道部署和提测时候用feature公共分支进行部署，问题修改在各自分支修改

其他约定

所有MR合并，都需要通过 云效平台 提交

MR 需要明确描述实现的功能、MR状态、最小化的RD评审人、最小化的Block评审人

如有方案设计，需附带相关文档帮助 CodeReview

当前项目如有额外代码和设计规范，MR 需要符合

发版规则

版本号规则：基本格式为 x.y.z。如每次的业务功能迭代，需要升级中间的版本号。如果有bugfix修复、代码重构优化、技术需求迭代，则升级最后一位。详见 semver语义化版本控制

版本发布前：

确认变更已验收或可控