前端編碼規范

YJNldm 發布于2019-08-23 13:53 / 2939人閱讀

摘要：去掉無用的代碼使用主動語態避免一連串松散結構的代碼邏輯把相關的變量函數放在一起。該處代碼運行正常，但可能由于時間趕或者其他原因，需要修正。此時需要對思路或詭異手段進行描述。

命名規范

變量名, 函數名小駝峰【命名法 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。

GPU云服務器云服務器規范編碼編碼規范 php編碼規范 js安全編碼規范

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/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