腳本之家服務器常用軟件

快捷導航

Go語言開發(fā)編程規(guī)范命令風格代碼格式

更新時間：2022年06月14日 11:32:06 作者：王中陽Go

這篇文章主要為大家介紹了Go語言開發(fā)編程規(guī)范命令風格代碼格式，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

前言

今天這篇文章是站在巨人的肩膀上，匯總了目前主流的開發(fā)規(guī)范，同時結合Go語言的特點，以及自己的項目經(jīng)驗總結出來的：爆肝分享兩千字Go編程規(guī)范。

后續(xù)還會更新更多優(yōu)雅的規(guī)范。

命名風格

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

反例：

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

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

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

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

正例：

renminbi / alibaba / taobao / youku / hangzhou

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

反例：

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

3. 【強制】公用的變量、類型、接口、結構、函數(shù)以及結構體的成員變量等命名使用UpperCamelCase風格。

正例：

GolangStruct / UserDO / XmlService / TcpUdpDeal / TaPromotion

反例：

Golangstruct / UserDo / XMLService / TCPUDPDeal / TAPromotion

4. 【強制】私有的變量、類型、接口、結構、函數(shù) 以及參數(shù) 名、局部變量都統(tǒng) 一使用 lowerCamelCase 風格，必須遵從駝峰形式。

正例：

localValue / getHttpMessage() / inputUserId

5. 【強制】常量命名命名使用 UpperCamelCase 風格，并使用 const 聲明，力求語義表達完整清楚，不要嫌名長。

正例：

const StatusOK = 200

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

正例：

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

7. 接口命名規(guī)范一般使用 er 結尾：單個函數(shù)的接口名以“er”作為后綴，接口的實現(xiàn)則去掉 er；兩個函數(shù)的接口名綜合兩個函數(shù)名，以 er 作為后綴，接口的實現(xiàn)則去掉 er ；三個以上函數(shù)的接口，抽象這個接口的功能，類似于結構體命名。

8. 【強制】數(shù)據(jù)和切片類型命名以 Arr 結尾，map 類型以 Map 結尾。相同功用的結構體可以根據(jù)功能采用相同的結尾， Api 請求以 Req 結尾，相應以 Res 結尾，數(shù)據(jù)結構體以 xxxModel 結尾， xxx 即為數(shù)據(jù)表名。

正例：

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

9. 【強制】返回結果主要為布爾類型的函數(shù)，函數(shù)名可以 is、has 等開頭

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

正例：

db-utils / package db_utils / package db_utils_test

反例：

services

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

12. 在常量與變量的命名時，表示類型的名詞放在詞尾，以提升辨識度。如規(guī)范【8】所示。

正例：

startTime / startDate

反例：

startedAt / startDt

13.如果模塊、接口、類、方法使用了設計模式，在命名時需體現(xiàn)出具體模式。

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

代碼格式

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

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

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

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

5. 【強制】采用 tab 字符縮進，寬度設置為 4 個空格

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

第二行相對第一行縮進一個 tab，從第三行開始，不再繼續(xù)縮進。
運算符與上文一起作為結尾。
方法調(diào)用的點符號與上文一起作為結尾。
方法調(diào)用中的多個參數(shù)需要換行時，在逗號后進行。
在括號前不要換行

7.【強制】函數(shù)參數(shù)在定義和傳入時，多個參數(shù)逗號后邊必須加空格。

控制語句

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

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

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

if condition { … return obj; } // 接著寫 else 的業(yè)務邏輯代碼;

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

【強制】請勿超過 3 層。

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

4. 【參考】下列情形，需要進行參數(shù)校驗：

調(diào)用頻次低的方法。
執(zhí)行時間開銷很大的方法。此情形中，參數(shù) 校驗時間幾乎可以忽略不計，但如果因為參數(shù)錯誤導致中間執(zhí)行回退，或者錯誤，那得不償失。
需要極高穩(wěn)定性和可用性的方法。
對外提供的開放接口，不管是 RPC/API/HTTP 接口。
敏感權限入口。

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

極有可能被循環(huán)調(diào)用的方法。但在方法說明里必須注明外部參數(shù)檢查要求。
底層調(diào)用頻度比較高的方法。畢竟是像純凈水過濾的最后一道，參數(shù)錯誤不太可能到底層才會暴露問題。一般 DAO 層與 Service 層都在同一個應用中，部署在同一臺服務器中，所以 DAO 的參數(shù)校驗，可以省略。