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

第Go語言開發(fā)編程規(guī)范命令風格代碼格式今天這篇文章是站在巨人的肩膀上，匯總了目前主流的開發(fā)規(guī)范，同時結合Go語言的特點，以及自己的項目經驗總結出來的：爆肝分享兩千字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聲明，力求語義表達完整清楚，不要嫌名長。

正例：

constStatusOK=200

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

正例：

ParamsErr:=errors.New(paramserr)

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

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

正例：

varuserArr[3]string/typeLoginReqstruct{}/typeUserDOstruct{}

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

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

正例：

db-utils/packagedb_utils/packagedb_utils_test

反例：

services

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

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

正例：

startTime/startDate

反例：

startedAt/startDt

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

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

1.【強制】如果是大括號內為空，則簡潔地寫成{}即可，大括號中間無需換行和空格；如果是非空代碼塊則：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ù)縮進。運算符與上文一起作為結尾。方法調用的點符號與上文一起作為結尾。方法調用中的多個參數(shù)需要換行時，在逗號后進行。在括號前不要換行

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

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

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

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

ifcondition{returnobj;}//接著寫else的業(yè)務邏輯代碼;

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

【強制】請勿超過3層。

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

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

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

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

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

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

正例：

//預編譯當前正則表達式re,_:=regexp.Compile(^hel+o)//是否匹配指定字符串isMatch:=re.MatchString(helloworld)

2.【推薦】及時清理不再使用的代碼段或配置信息。說明：對于垃圾代碼或過時配置，堅決清理干凈，避免程序過度臃腫，代碼冗余。正例：對于暫時被注釋掉，后續(xù)可能恢復使用的代碼片斷，在注釋代碼上方，統(tǒng)一規(guī)定使用三個斜杠(///)來說明注釋掉代碼的理由。

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