前端開發編碼規範

mygood發表於2018-12-13
前端

命名規範

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

相關文章