前端编码规范

命名规范

  • 变量名, 函数名 小驼峰【命名法 camel Case】: numberOfPeople 第一个单词的首字母小写;第二个单词开始每个单词的的首字母大写
  • 组件名 大驼峰【命名法 Camel Case】: NumberOfPeople 每一个单词的首字母都大写
  • css样式名 中横线【命名法 kabab case】: number-of-people 单词小写用(-)中横线分隔
  • 常量名, graphql query 与 mutation变量名: 蛇底式大写【命名法 upper snake case】: NUMBER_OF_PEOPLE 复合词或短语中的各个单词之间:下划线(_)分隔并且没有空格
  • 禁用小写加下划线 :number_of_people
命名方式应用范围备注
camel Case变量名, 函数名
Camel Case组件名, 枚举名枚举: SaveType = { BUILD: ‘BUILD’ }
kabab casecss样式名
upper snake case常量名, graphql query与 mutation变量名
snake case禁止使用

应用范围

<div class=”bi-table”>

<colgroup> <col width=”auto” /> <col width=”auto” /> <col width=”auto” /> </colgroup>

<div data-type=”p”>结构</div> <div data-type=”p”>应用范围</div> <div data-type=”p”>备注</div>
<div data-type=”p”>动+宾 (+ 副词)</div> <div data-type=”p”>函数名, graphql mutation名称</div> <div data-type=”p”></div>
<div data-type=”p”>名词(定语+名词)</div> <div data-type=”p”>组件名, 类名</div> <div data-type=”p”></div>
<div data-type=”p”>形容词 (名词+形容词)</div> <div data-type=”p”>动词被动形态</div> <div data-type=”p”>(be+xxx)</div> <div data-type=”p”>状态变量</div> <div data-type=”p”>控制对话框是否显示: dialogVisible</div> <div data-type=”p”></div> <div data-type=”p”>尽可能不要用 is+形容词结构, 如 isSelected, 用 selected 就可以了.</div> <div data-type=”p”></div> <div data-type=”p”>is+名词结构可以使用, 如 isEnterprise</div>

</div>

名词

__camel Case__: numberOfPeople
__Camel Case__: NumberOfPeople
__kabab case__: number-of-people
__snake case__: number_of_people
__upper snake case__: NUMBER_OF_PEOPLE

Merge Request Checklist

  • 检查是否和目标分支有冲突
  • 检查是否修复所有 dn test 的问题
  • 检查目录、文件名拼写
  • 检查 graphql 文件名拼写,Query 首字母大写的 CamelCase,Mutation 首字母小写的 camelCase
  • 检查 conf 中的命名是否符合规范

标准的项目研发流程包括以下几个阶段:

* 评审阶段
    * 需求评审
    * 交互评审
    * 视觉评审
* 开发阶段
    * 原型开发
    * 用户交互事件响应
    * 接入Mock数据
    * 后台接口数据对接
* 联调阶段
    * 预发联调
    * 整个业务串联测试流程
* 测试阶段
    * 埋点开发及验证
    * 自测用例覆盖
    * 交付提测
    * bug修复
* 发布上线

写作的基本准则(优化)

  基本上写作的基本准则的每一部分都能应用在代码上:
    ● 让段落成为文章的基本结构:每一段对应一个主题。
    ● 去掉无用的单词。 .
    ● 使用主动语态。
    ● 避免一连串松散的句子。
    ● 将相关的词语放在一起。
    ● 陈述句用主动语态。
    ● 平行的概念用平行的结构。
  这些对应的 用在前端的代码风格上
    1. 让函数成为代码的基本单元。每个函数做一件事。
    2. 去掉无用的代码
    3. 使用主动语态
    4. 避免一连串松散结构的代码逻辑
    5. 把相关的变量、函数放在一起。
    6. 表达式和陈述语句中使用主动语态。
    7. 用并行的代码表达并行的概念。

Git分支

存在三种短期分支

        功能分支(feature branch)
        补丁分支(hotfix branch)
        预发分支(release branch)

Git Commit type

bug fix – 组件 bug 修复;
breaking change – 不兼容的改动;
new feature – 新功能

提交 Commit 类型前缀 主要如下:
feat: 新特性功能
fix: 缺陷修复bug
docs: 文档相关
style: 样式修改、错别字修改、代码的格式化改动,代码逻辑并未产生任何变化
refactor: 重构或其他方面的优化
perf: 性能提升
test: 增加测试
chore: 业务无关修改,如:发版、构建工具链修改等
scope 可选,作用域标识,指明你需改的代码所属作用域
subject 真实 Commit 描述,能说明白即可,字数不用太多

Git日常操作

git diff 查看修改内容

git bisect  二分查找法 定位问题

git clone git@github.com:UED/test.git 

git fetch origin    //取得远程更新,这里可以看做是准备要取了

git merge origin/master  //把更新的内容合并到本地分支/master  


git remote -v //查看当前项目远程连接的是哪个仓库地址。
  
git push -u origin master //    将本地的项目提交到远程仓库中。

git push -u origin master -f // 强制提交

git commit --amend 修改上一次 commit

抛弃本地所有的修改,回到远程仓库的状态。
git fetch --all && git reset --hard origin/master

        git clone 地址  clone
        git branch 查看分支
        git branch daily/0.0.1 创建分支

        # 切换分支,格式为 daily/x.y.z
        git checkout daily/0.0.3
        # 提交代码
        git pull
        git add *
        git commit -m 'feat: 完成了某个新功能'

        # 将代码push到gitlab daily环境
        git push origin daily/0.0.3

        # 打publish tag将代码发布到CDN
        --tag 创建一个里程碑
        git tag publish/0.0.3
        git push origin publish/0.0.3

代码中的注释类型前缀

TODO: 有功能待实现。此时需要对将要实现的功能进行简单说明。
FIXME: 该处代码运行正常,但可能由于时间赶或者其他原因,需要修正。此时需要对如何修正进行简单说明。
HACK: 为修正某些问题而写的不太好或者使用了某些诡异手段的代码。此时需要对思路或诡异手段进行描述。
    # 标题行:50个字符以内,描述主要变更内容
    #
    # 主体内容:更详细的说明文本,建议72个字符以内。 需要描述的信息包括:
    #
    # * 为什么这个变更是必须的? 它可能是用来修复一个bug,增加一个feature,提升性能、可靠性、稳定性等等
    # * 他如何解决这个问题? 具体描述解决问题的步骤
    # * 是否存在副作用、风险?
    #
    # 尾部:如果需要的化可以添加一个链接到issue地址或者其它文档,或者关闭某个issue。
    原文作者:马云云_理想青年
    原文地址: https://segmentfault.com/a/1190000017268456
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞