前端编码规范

YJNldm 发布于2019-08-23 13:53 / 2829人阅读

摘要：去掉无用的代码使用主动语态避免一连串松散结构的代码逻辑把相关的变量函数放在一起。该处代码运行正常，但可能由于时间赶或者其他原因，需要修正。此时需要对思路或诡异手段进行描述。

命名规范

变量名, 函数名小驼峰【命名法 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 case	css样式名
upper snake case	常量名, graphql query与 mutation变量名
snake case	禁止使用

应用范围

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

名词

__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。

专线服务超融合服务器规范编码编码规范 php编码规范 js安全编码规范

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/99741.html

前端编码规范之：样式（scss）编码规范

摘要：前端编码规范之使用规范前端编码规范之样式编码规范前端编码规范之结构规范前端编码规范之最佳实践前端编码规范之编码规范命名的原则是通俗易懂，尽量保持不重复冲突，尽量不要用。我觉得应该避免出现出现这种方式用预处理器拼接出来的名称，会生成。前端编码规范之：Git使用规范前端编码规范之：样式（scss）编码规范前端编码规范之：HTML结构规范前端编码规范之：Vue最佳实践前端编码规范...

reclay 2019-08-29 16:58 评论0 收藏0
前端编码规范

摘要：前言首先，写这篇代码规范是为了我自己在以后的项目中方便引用，让前端人员统一标准，方便在开发中保持代码的一致性，代码规范是在的编码规范上的基础上做的修改，下面只列举出一些不一样的地方，基本的规范参照编码规范要求使用。前言首先，写这篇代码规范是为了我自己在以后的项目中方便引用，让前端人员统一标准，方便在开发中保持代码的一致性，代码规范是在bootstrap的编码规范上的基础上做的修改，...

nicercode 2019-08-19 17:20 评论0 收藏0
前端编码规范

摘要：前言首先，写这篇代码规范是为了我自己在以后的项目中方便引用，让前端人员统一标准，方便在开发中保持代码的一致性，代码规范是在的编码规范上的基础上做的修改，下面只列举出一些不一样的地方，基本的规范参照编码规范要求使用。前言首先，写这篇代码规范是为了我自己在以后的项目中方便引用，让前端人员统一标准，方便在开发中保持代码的一致性，代码规范是在bootstrap的编码规范上的基础上做的修改，...

gggggggbong 2019-08-28 18:29 评论0 收藏0
前端编码规范

摘要：前言首先，写这篇代码规范是为了我自己在以后的项目中方便引用，让前端人员统一标准，方便在开发中保持代码的一致性，代码规范是在的编码规范上的基础上做的修改，下面只列举出一些不一样的地方，基本的规范参照编码规范要求使用。前言首先，写这篇代码规范是为了我自己在以后的项目中方便引用，让前端人员统一标准，方便在开发中保持代码的一致性，代码规范是在bootstrap的编码规范上的基础上做的修改，...

xushaojieaaa 2019-08-01 15:02 评论0 收藏0
前端、HTML+CSS+JS编写规范（终极版）

摘要：文档规范和文档必须采用编码格式文档必须使用的标准文档格式编写规范和的标签属性类名都必须使用小写字母和的属性类名命名必须具有语义化代码必须保持文档结构清晰，必须合理的进行代码缩进文件禁止样式表内引用文件编写格式，样式代码保持一行，多个选择器 HTMLCSS文档规范 HTML和CSS文档必须采用UTF-8编码格式； HTML文档必须使用HTML5的标准文档格式； HTMLCSS编写规范...

jsyzchen 2019-08-01 18:15 评论0 收藏0
前端、HTML+CSS+JS编写规范（终极版）

摘要：文档规范和文档必须采用编码格式文档必须使用的标准文档格式编写规范和的标签属性类名都必须使用小写字母和的属性类名命名必须具有语义化代码必须保持文档结构清晰，必须合理的进行代码缩进文件禁止样式表内引用文件编写格式，样式代码保持一行，多个选择器 HTMLCSS文档规范 HTML和CSS文档必须采用UTF-8编码格式； HTML文档必须使用HTML5的标准文档格式； HTMLCSS编写规范...

_Dreams 2019-08-22 11:23 评论0 收藏0