前端開發編碼規範
命名規範
- 變數名, 函式名 小駝峰【命名法 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。
相關文章
- 程式碼規範之前端編寫碼規範前端
- web前端開發編碼規範及效能優化Web前端優化
- 前端安全編碼規範前端
- WEB前端編碼規範Web前端
- 前端開發規範前端
- 前端單體編碼規範整理前端
- 前端設計與編碼規範前端
- Vue前端開發規範Vue前端
- web前端開發規範Web前端
- web前端開發規範總結Web前端
- Web前端開發規範手冊Web前端
- stylus編碼規範
- html編碼規範HTML
- Pear 編碼規範
- CSS編碼規範CSS
- Javascript編碼規範JavaScript
- python編碼規範Python
- ? 前端開發行為指導規範前端
- .Net Core 編碼規範
- 常見編碼規範
- .Net編碼規範整理
- (轉)豆瓣網前端開發規範之 【CSS】前端CSS
- 前端開發規範 從制定到實施前端
- HTML編碼規範建議HTML
- PHP編碼風格規範PHP
- Java語言編碼規範Java
- 前端規範之HTML 規範前端HTML
- 前端規範之javascript規範前端JavaScript
- 前端規範之CSS規範前端CSS
- 前端規範之nodeJs 規範前端NodeJS
- 開發規範
- MySQL資料庫規範 (設計規範+開發規範+操作規範)MySql資料庫
- 前端工程程式碼規範(四)——JS前端JS
- 前端工程程式碼規範(二)——HTML前端HTML
- 前端規範之CSS規範(Stylelint)前端CSS
- PHP – 編碼規範 v1.0PHP
- Uber Go 語言編碼規範Go
- 編寫shell指令碼的規範指令碼