1. 程式人生 > 程式設計 >一文了解Go語言中編碼規範的使用

一文了解Go語言中編碼規範的使用

每個語言都有自己特色的編碼規範,學習該語言的命名規範,能讓你寫出來的程式碼更加易讀,更加不容易出現一些低階錯誤。

本文根據個人編碼習慣以及網路上的一些文章,整理了一些大家能用上的編碼規範,可能是一些主流方案,但不代表官方,這一點先宣告一下。

1. 檔案命名

由於 Windows平臺檔名不區分大小寫,所以檔名應一律使用小寫

不同單詞之間用下劃線分詞,不要使用駝峰式命名

如果是測試檔案,可以以 _test.go 結尾

檔案若具有平臺特性,應以 檔名_平臺.go 命名,比如 utils_ windows.go,utils_linux.go,可用的平臺有:windows,unix,posix,plan9,darwin,bsd,linux,freebsd,nacl,netbsd,openbsd,solaris,dragonfly,notbsd, android,stubs

一般情況下應用的主入口應為 main.go,或者以應用的全小寫形式命名。比如MyBlog 的入口可以為 myblog.go

2. 常量命名

目前在網路上可以看到主要有兩種風格的寫法

第一種是駝峰命名法,比如 appVersion

第二種使用全大寫且用下劃線分詞,比如 APP_VERSION

這兩種風格,沒有孰好孰弱,可自由選取,我個人更傾向於使用第二種,主要是能一眼與變數區分開來。

如果要定義多個變數,請使用 括號 來組織。

const (
  APP_VERSION = "0.1.0"
 CONF_PATH = "/etc/xx.conf"
)

3. 變數命名

和常量不同,變數的命名,開發者們的喜好就比較一致了,統一使用 駝峰命名法

  1. 在相對簡單的環境(物件數量少、針對性強)中,可以將完整單詞簡寫為單個字母,例如:user寫為u
  2. 若該變數為 bool 型別,則名稱應以 Has,Is,Can 或 Allow 開頭。例如:isExist ,hasConflict 。
  3. 其他一般情況下首單詞全小寫,其後各單詞首字母大寫。例如:numShips 和 startDate 。
  4. 若變數中有特有名詞(以下列出),且變數為私有,則首單詞還是使用全小寫,如 apiClient。
  5. 若變數中有特有名詞(以下列出),但變數不是私有,那首單詞就要變成全大寫。例如:APIClient,URLString

這裡列舉了一些常見的特有名詞:

// A GonicMapper that contains a list of common initialisms taken from golang/lint
var LintGonicMapper = GonicMapper{
  "API":  true,"ASCII": true,"CPU":  true,"CSS":  true,"DNS":  true,"EOF":  true,"GUID": true,"HTML": true,"HTTP": true,"HTTPS": true,"ID":  true,"IP":  true,"JSON": true,"LHS":  true,"QPS":  true,"RAM":  true,"RHS":  true,"RPC":  true,"SLA":  true,"SMTP": true,"SSH":  true,"TLS":  true,"TTL":  true,"UI":  true,"UID":  true,"UUID": true,"URI":  true,"URL":  true,"UTF8": true,"VM":  true,"XML":  true,"XSRF": true,"XSS":  true,}

4. 函式命名

  1. 函式名還是使用 駝峰命名法
  2. 但是有一點需要注意,在 Golang 中是用大小寫來控制函式的可見性,因此當你需要在包外訪問,請使用 大寫字母開頭
  3. 當你不需要在包外訪問,請使用小寫字母開頭

另外,函式內部的引數的排列順序也有幾點原則

  1. 引數的重要程度越高,應排在越前面
  2. 簡單的型別應優先複雜型別
  3. 儘可能將同種型別的引數放在相鄰位置,則只需寫一次型別

5. 介面命名

使用駝峰命名法,可以用 type alias 來定義大寫開頭的 type 給包外訪問。

type helloWorld interface {
  func Hello();
}

type SayHello helloWorld

當你的介面只有一個函式時,介面名通常會以 er 為字尾

type Reader interface {
  Read(p []byte) (n int,err error)
}

5. 註釋規範

註釋分為

5.1 包註釋

位於 package 之前,如果一個包有多個檔案,只需要在一個檔案中編寫即可
如果你想在每個檔案中的頭部加上註釋,需要在版權註釋和 Package前面加一個空行,否則版權註釋會作為Package的註釋。

// Copyright 2009 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package net

如果是特別複雜的包,可單獨建立 doc.go 檔案說明

5.2 程式碼註釋

用於解釋程式碼邏輯,可以有兩種寫法

單行註釋使用 // ,多行註釋使用 /* comment */

// 單行註釋

/*
多
行
注
釋
*/

另外,對於程式碼註釋還有一些更加苛刻的要求,這個看個人了,摘自網路:

所有匯出物件都需要註釋說明其用途;非匯出物件根據情況進行註釋。
如果物件可數且無明確指定數量的情況下,一律使用單數形式和一般進行時描述;否則使用複數形式。
包、函式、方法和型別的註釋說明都是一個完整的句子。
句子型別的註釋首字母均需大寫;短語型別的註釋首字母需小寫。
註釋的單行長度不能超過 80 個字元。
型別的定義一般都以單數形式描述:

// Request represents a request to run a command. type Request struct { ...

如果為介面,則一般以以下形式描述:

 // FileInfo is the interface that describes a file and is returned by Stat and Lstat.
 type FileInfo interface { ...

函式與方法的註釋需以函式或方法的名稱作為開頭:

// Post returns *BeegoHttpRequest with POST method.

如果一句話不足以說明全部問題,則可換行繼續進行更加細緻的描述:

 // Copy copies file from source to target path.
 // It returns false and error when error occurs in underlying function calls.

若函式或方法為判斷型別(返回值主要為 bool 型別),則以 <name> returns true if 開頭:

 // HasPrefix returns true if name has any string in given slice as prefix.
 func HasPrefix(name string,prefixes []string) bool { ...

5.3 特別註釋

  • TODO:提醒維護人員此部分程式碼待完成
  • FIXME:提醒維護人員此處有BUG待修復
  • NOTE:維護人員要關注的一些問題說明

6. 包的匯入

單行的包匯入

import "fmt"

多個包匯入,請使用 {} 來組織

import {
 "fmt"
 "os"
}

另外根據包的來源,對排版還有一定的要求

標準庫排最前面,第三方包次之、專案內的其它包和當前包的子包排最後,每種分類以一空行分隔。
儘量不要使用相對路徑來匯入包。

import (
  "fmt"
  "html/template"
  "net/http"
  "os"
 
  "github.com/codegangsta/cli"
  "gopkg.in/macaron.v1"
 
  "github.com/gogits/git"
  "github.com/gogits/gfm"
 
  "github.com/gogits/gogs/routers"
  "github.com/gogits/gogs/routers/repo"
  "github.com/gogits/gogs/routers/user"
)

7. 善用 gofmt

除了命名規範外,Go 還有很多格式上的規範,比如

  1. 使用 tab 進行縮排
  2. 一行最長不要超過 80 個字元

因此在格式上的問題,你大部分都可以放心交由 gofmt 幫你調整。關於 gofmt 的文章還在寫,應該這兩天就會更新。你可以過兩天再來看看。

參考文章:

Go語言(Golang)編碼規範

到此這篇關於一文了解Go語言中編碼規範的使用的文章就介紹到這了,更多相關Go語言編碼規範內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們!