Go語言開發程式設計規範命令風格程式碼格式

前言

今天這篇文章是站在巨人的肩膀上，彙總了目前主流的開發規範，同時結合Go語言的特點，以及自己的專案經驗總結出來的：爆肝分享兩千字Go程式設計規範。

後續還會更新更多優雅的規範。

命名風格

1. 【強制】程式碼中的命名均不能以下劃線或美元符號開始，也不能以下劃線或美元符號結束。 

反 例 ： 

_name / __name / $name / name_ / name$ / name__  

2. 【強制】程式碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。 

說明：正確的英文拼寫和語法可以讓閱讀者易於理解，避免歧義。

注意，純拼音命名方式更要避免採用。 

正例：

renminbi / alibaba / taobao / youku / hangzhou

等國際通用的名稱，可視同英文。

反 例 ：

DaZhePromotion [ 打 折 ] / getPingfenByName() [評分] / int某變數 = 3

3. 【強制】公用的變數、型別、介面、結構、函數以及結構體的成員變數等命名使用UpperCamelCase風格。

正例：

GolangStruct / UserDO / XmlService / TcpUdpDeal / TaPromotion

反例：

Golangstruct / UserDo / XMLService / TCPUDPDeal / TAPromotion

4. 【強制】私有的變數、型別、介面、結構、函數 以 及 參 數 名 、 局 部 變 量 都 統 一 使 用 lowerCamelCase 風格，必須遵從駝峰形式。

正 例 ：

localValue / getHttpMessage() / inputUserId

5. 【強制】常數命名命名使用 UpperCamelCase 風格，並使用 const 宣告，力求語意表達完整 清楚，不要嫌名長。

正例：

const StatusOK = 200

6. 抽象結構命名使用 Abstract 或 Base 開頭； 異常類命名使用 Err 結尾； 測試類命名以 Test 開頭，以它要測試的函數的 名稱結尾。

正 例 ：

 ParamsErr := errors.New(“params err”)

7. 介面命名規範一般使用 er 結尾：單個函數的介面名以“er”作為字尾，介面的實現則去掉 er； 兩個函數的介面名綜合兩個函數名，以 er 作為 字尾，介面的實現則去掉 er ； 三個以上函數的介面，抽象這個介面的功能，類似於結構體命名。

8. 【強制】資料和切片型別命名以 Arr 結尾，map 型別以 Map 結尾。相同功用的結構體可以根據功能採 用相同的結尾， Api 請求以 Req 結尾， 相應以 Res 結尾，資料結構體以 xxxModel 結尾， xxx 即為資料表名。

正例：

var userArr [3]string / type LoginReq struct{} / type UserDO struct{}

9. 【強制】返回結果主要為布林型別的函數，函數名可以 is、has 等開頭

10. 【強制】工程名統一使用小寫，單詞之間使 用 - 分割。包目錄名一律使用小寫，儘量採用一 個單詞命名，單詞間不用符號分割，統一使用單 數形式，但是結構體名如果有複數含義，結構體 名可以使用複數形式。包目錄下的包名（ package namepackage ），如非 main 函數，和包目錄名保持一直且單詞間用 _ 分隔，測試檔案以 _test 結 尾。

正 例 ：

 db-utils / package db_utils / package db_utils_test

反例：

services

11. 為了達到程式碼自解釋的目標，任何自定義程式設計元 素在命名時，使用盡量完整的單詞組合來表達其意。反例：var a int 的隨意命名方式。

12. 在常數與變數的命名時，表示型別的名詞放在詞尾，以提升辨識度。如規範【8】所示。

正例：

startTime / startDate

反例：

startedAt / startDt

13.如果模組、介面、類、方法使用了設計模式，在命名時需體現出具體模式。

說明：將設計模式體現在名字中，有利於閱讀者 快速理解架構設計理念。

程式碼格式

1. 【強制】如果是大括號內為空，則簡潔地寫成{} 即可，大括號中間無需換行和空格；如果是非空 程式碼塊則： 1） 左大括號前不換行。 2） 左大括號後換行。 3） 右大括號前換行。 4） 右大括號後還有 else 等程式碼則不換行；表 示終止的右大括號後必須換行。

2. 【強制】左小括號和字元之間不出現空格；同樣， 右小括號和字元之間也不出現空格；而左大括號 前需要空格。 反例：if (空格 a == b 空格)

3. 【強制】if / for / switch 等保留字與括號之間都必 須加空格。

4. 【強制】任何二目、三目運運算元的左右兩邊都需 要加一個空格。 說明：運運算元包括賦值運運算元= 、邏輯運運算元&&、 加減乘除符號等。

5. 【強制】採用 tab 字元縮排，寬度設定為 4 個 空格

6. 【強制】單行字元數限制不超過 120 個，超出 需要換行，換行時遵循如下原則：

• 第二行相對第一行縮排一個 tab，從第三行 開始，不再繼續縮排。
• 運運算元與上文一起作為結尾。
• 方法呼叫的點符號與上文一起作為結尾。
• 方法呼叫中的多個引數需要換行時，在逗號 後進行。
• 在括號前不要換行

7.【強制】函數引數在定義和傳入時，多個引數逗 號後邊必須加空格。

控制語句

1.【強制】在一個 switch 塊內，每個 case 無需聲 明 break 來 終 止 ， 如 果 想 順 序 執 行 使 用 fallthrough ；在一個 switch 塊內，都必須包含 一個 default 語句並且放在最後，即使它什麼代 碼也沒有。

2.【強制】在高並行場景中，避免使用”等於”判 斷作為中斷或退出的條件。 說明：如果並行控制沒有處理好，容易產生等值 判斷被“擊穿”的情況，使用大於或小於的區間 判斷條件來代替。 反例：判斷剩餘獎品數量等於 0 時，終止發放 獎品，但因為並行處理錯誤導致獎品數量瞬間變成了負數， 這樣的話，活動無法終止。

3.【推薦】表達異常的分支時，少用 if-else 方式， 這種方式可以改寫成：

if condition { … return obj; } // 接著寫 else 的業務邏輯程式碼;

說明：如果非使用 if()…else if()…else…方式表 達邏輯，避免後續程式碼維護困難，

【強制】請勿 超過 3 層。

正例：超過 3 層的 if-else 的邏輯判斷程式碼可 以使用衛語句、策略模式、狀態模式等來實現， 其中衛語句即程式碼邏輯先考慮失敗、異常、中斷、 退出等直接返回的情況，以方法多個出口的方 式，解決程式碼中判斷分支巢狀的問題，這是逆向 思維的體現。

4. 【參考】下列情形，需要進行引數校驗：

• 呼叫頻次低的方法。
• 執行時間開銷很大的方法。此情形中，引數 校驗時間幾乎可以忽略不計，但如果因為引數錯 誤導致中間執行回退，或者錯誤，那得不償失。
• 需要極高穩定性和可用性的方法。
• 對 外 提 供 的 開 放 接 口 ， 不 管 是 RPC/API/HTTP 介面。
• 敏感許可權入口。

5. 【參考】下列情形，不需要進行引數校驗：

• 極有可能被迴圈呼叫的方法。但在方法說明 裡必須註明外部引數檢查要求。
• 底層呼叫頻度比較高的方法。畢竟是像純淨 水過濾的最後一道，引數錯誤不太可能到底層才 會暴露問題。一般 DAO 層與 Service 層都在 同一個應用中，部署在同一臺伺服器中，所以 DAO 的引數校驗，可以省略。

雜項

1. 【強制】在使用正規表示式時，利用好其預編譯 功能，可以有效加快正則匹配速度。

 正例：

 // 預編譯當前正規表示式re, _ := regexp.Compile("^hel+o") // 是否匹配指定字串 isMatch := re.MatchString(“hello world”)

2. 【推薦】及時清理不再使用的程式碼段或設定資訊。 說明：對於垃圾程式碼或過時設定，堅決清理乾淨， 避免程式過度臃腫，程式碼冗餘。 正例：對於暫時被註釋掉，後續可能恢復使用的 程式碼片斷，在註釋程式碼上方，統一規定使用三個 斜槓(///)來說明註釋掉程式碼的理由。

異常紀錄檔

1. 【強制】使用控制流機制應對錯誤，通過從函數 返回錯誤作為附加返回值來指示錯誤，如果函數 有多個返回值，習慣上將錯誤值作為最後一個結 果返回。如果錯誤只有一種情況，結果通常設定為布林型別。nil 值表示沒有錯誤。 正例：res, err := somepkgAction()

2. 【強制】對於總是成功返回的函數，不必返回錯誤。

3. 【強制】錯誤資訊的首字母小寫且避免換行

更多

還會更新更多優雅的規範實踐...

沒有規矩不成方圓，團隊開發中只有嚴格按照規範進行，才能避免開發一時爽，維護火葬場的困頓局面~

以上就是Go語言開發程式設計規範命令風格程式碼格式的詳細內容，更多關於Go程式設計規範命令風格程式碼格式的資料請關注it145.com其它相關文章！