[Go] 编码规范

gofmt

大部分的格式问题可以通过 gofmt 解决,gofmt 自动格式化代码,保证所有的Go代码与官方推荐的格式保持一致,于是所有格式有关问题,都以 gofmt 的结果为准。

注释

在编码阶段应该同步写好变量、函数、包的注释,最后可以利用godoc导出文档。注释必须是完整的句子,句子的结尾应该用句号作为结尾(英文句号)。注释推荐用英文,可以在写代码过程中锻炼英文的阅读和书写能力。而且用英文不会出现各种编码的问题。

每个包都应该有一个包注释,一个位于 package 子句之前的块注释或行注释。包如果有多个 go 文件,只需要出现在一个 go 文件中即可。

// ping包实现了常用的ping相关的函数
package ping 

导出函数注释,第一条语句应该为一条概括语句,并且使用被声明的名字作为开头。

// 求 a 和 b 的和,返回 sum。
func Myfunction(sum int) (a, b int) { }

命名

  • 需要注释来补充的命名就不算是好命名。
  • 使用可搜索的名称:单字母名称和数字常量很难从一大堆文字中搜索出来。单字母名称仅适用于短方法中的本地变量,名称长短应与其作用域相对应。若变量或常量可能在代码中多处使用,则应赋其以便于搜索的名称。
  • 做有意义的区分:Product 和 ProductInfo 和 ProductData 没有区别,NameString 和 Name 没有区别,要区分名称,就要以读者能鉴别不同之处的方式来区分 。
  • 函数命名规则:驼峰式命名,名字可以长但是得把功能,必要的参数描述清楚,函数名名应当是动词或动词短语,如 postPayment、deletePage、save。并依 Javabean 标准加上 get、set、is 前缀。例如:xxx + With + 需要的参数名 + And + 需要的参数名 + …..
  • 结构体命名规则:结构体名应该是名词或名词短语,如 Custome、WikiPage、Account、AddressParser,避免使用 Manager、Processor、Data、Info 这样的类名,类名不应当是动词。
  • 包名命名规则:包名应该为小写单词,不要使用下划线或者混合大小写。
  • 接口命名规则:单个函数的接口名以“er”作为后缀,如 Reader,Writer。接口的实现则去掉“er”。
type Reader interface {
        Read(p []byte) (n int, err error)
}

两个函数的接口名综合两个函数名

type WriteFlusher interface {
    Write([]byte) (int, error)
    Flush() error
}

三个以上函数的接口名,抽象这个接口的功能,类似于结构体名

type Car interface {
    Start([]byte)
    Stop() error
    Recover()
}

常量

常量均需使用全部大写字母组成,并使用下划线分词:

const APP_VER = "1.0"

如果是枚举类型的常量,需要先创建相应类型:

type Scheme string

const (
    HTTP  Scheme = "http"
    HTTPS Scheme = "https"
)

如果模块的功能较为复杂、常量名称容易混淆的情况下,为了更好地区分枚举类型,可以使用完整的前缀:

type PullRequestStatus int

const (
    PULL_REQUEST_STATUS_CONFLICT PullRequestStatus = iota
    PULL_REQUEST_STATUS_CHECKING
    PULL_REQUEST_STATUS_MERGEABLE
)

变量

变量命名基本上遵循相应的英文表达或简写,在相对简单的环境(对象数量少、针对性强)中,可以将一些名称由完整单词简写为单个字母,例如:

  • user 可以简写为 u
  • userID 可以简写 uid 
    若变量类型为 bool 类型,则名称应以 Has, Is, Can 或 Allow 开头:
var isExist bool
var hasConflict bool
var canManage bool
var allowGitHook bool

变量命名惯例

变量名称一般遵循驼峰法,但遇到特有名词时,需要遵循以下规则:

  • 如果变量为私有,且特有名词为首个单词,则使用小写,如 apiClient
  • 其它情况都应当使用该名词原有的写法,如 APIClient、repoID、UserID
  • 错误示例:UrlArray,应该写成 urlArray 或者 URLArray

下面列举了一些常见的特有名词:

// 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,
}

struct 规范

struct 申明和初始化格式采用多行:

定义如下:

type User struct{
    Username  string
    Email     string
}

初始化如下:

u := User{
    Username: "test",
    Email:    "[email protected]",
}

控制结构

if 接受初始化语句,约定如下方式建立局部变量

if err := file.Chmod(0664); err != nil {
    return err
}

for 采用短声明建立局部变量

sum := 0
for i := 0; i < 10; i++ {
    sum += i
}

return 尽早 return:一旦有错误发生,马上返回

f, err := os.Open(name)
if err != nil {
    return err
}

d, err := f.Stat()
if err != nil {
    f.Close()
    return err
}

codeUsing(f, d)

错误处理

  • error作为函数的值返回,必须对error进行处理
  • 错误描述如果是英文必须为小写,不需要标点结尾
  • 采用独立的错误流进行处理

不要采用下面的处理错误写法

if err != nil {
    // error handling
} else {
    // normal code
}

采用下面的写法

if err != nil {
    // error handling
    return // or continue, etc.
}
// normal code

使用函数的返回值时,则采用下面的方式

x, err := f()
if err != nil {
    // error handling
    return
}
// use x

panic

尽量不要使用panic,除非你知道你在做什么

import

对 import 的包进行分组管理,用换行符分割,而且标准库作为分组的第一组。如果你的包引入了三种类型的包,标准库包,程序内部包,第三方包,建议采用如下方式进行组织你的包

package main

import (
    "fmt"
    "os"

    "kmg/a"
    "kmg/b"

    "code.google.com/a"
    "github.com/b"
)

在项目中不要使用相对路径引入包:

// 错误示例
import “../net”

// 正确的做法
import “github.com/repo/proj/src/net”

goimports 会自动帮你格式化

参数传递

  • 对于少量数据,不要传递指针
  • 对于大量数据的 struct 可以考虑使用指针
  • 传入参数是 map,slice,chan 不要传递指针,因为 map,slice,chan 是引用类型,不需要传递指针的指针

单元测试

单元测试文件名命名规范为 example_test.go

测试用例的函数名称必须以 Test 开头,例如:TestExample

参考:

https://gocn.io/article/1

http://blog.csdn.net/myzlhh/article/details/52269591

时间: 2024-10-12 19:25:02

[Go] 编码规范的相关文章

java编码规范

右括号") "与其后面的关键字之间,关键字与其后面的左括号"("或"{"之间,以及"}"与"{"之间,要以一个空格隔开:除". "外,所有二元操作符的前.后要加空格:在逗号后边加一个空格. 说明: 一个紧跟着括号的关键词应该被空格分开: 空白应该位于参数列表中逗号的后面: 所有的二元运算符,除了".",应该使用空格将之与操作数分开.一元操作符和操作数之间不应该加空格,

我也学php:编码规范/翻译自PSR

PHP社区百花齐放,拥有大量的函数库.框架和组件.PHP开发者通常会在自己的项目中使用若干个外部库,因而PHP代码遵循或尽量接近同一个代码风格就非常重要,可以让开发者方便地把多个代码库集成在自己的项目中. 框架互操作组(即PHP标准组)发布了一系列代码风格推荐标准,即PSR-0,PSR-1,PSR-2和PSR-3. 不要让这些名称所混淆,这些推荐仅是一些被其它项目所遵循的规则,如Drupal, Zend, Symfony, CakePHP, phpBB, AWS SDK, FuelPHP, Li

阿里Java编码规范

详细,全面 很不错 阿里 Java编码规范

html编码规范

不久前接到老大下达的任务,要拟定一份公司前端编码规范的草稿,参考了各大公司的编码规范,结合现在公司的特点,整理出以下编码规范: html规范 1 文件相关 (1) 文件名以英文为主,可以使用下划线(如active.html),压缩包以项目名+日期的形式. (2) 统一使用utf-8编码. (3) css.js发布到线上都需要压缩. (4) 在追求高度优化的站点,需要对图片也进行无损压缩. 2 代码风格 2.1 命名 (1) 元素 id 必须保证页面唯一.(解释:同一个页面中,不同的元素包含相同的

【转】Airbnb React编码规范

Airbnb的编码规范是在业界非常流行的一套规范,而且它一直都在进化,推出最新技术的规范 原文:https://zhuanlan.zhihu.com/p/20616464 用更合理的方式书写React和JSX 基本规则 每个文件只包含一个React组件: 但是无状态, 或者 Pure 组件 允许一个文件包含多个组件.eslint: react/no-multi-comp. 始终使用 JSX 语法; 不要使用 React.createElement方法,除非初始化 app 的文件不是 JSX 格式

Bootstrap编码规范

黄金定律 永远遵循同一套编码规范 -- 可以是这里列出的,也可以是你自己总结的.如果你发现本规范中有任何错误,敬请指正.通过 open an issue on GitHub为本规范添加或贡献内容. 不管有多少人共同参与同一项目,一定要确保每一行代码都像是同一个人编写的. HTML 语法 用两个空格来代替制表符(tab) -- 这是唯一能保证在所有环境下获得一致展现的方法. 嵌套元素应当缩进一次(即两个空格). 对于属性的定义,确保全部使用双引号,绝不要使用单引号. 不要在自闭合(self-clo

iOS:Cocoa编码规范 -[译]Coding Guidelines for Cocoa

--原文地址:https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/FrameworkImpl.html Cocoa编码规范 --前言 用公共API开发一个Cocoa框架,插件,或其他可执行目标,里面的命名编写和规范不同于一般应用程序的开发.因为你开发出来东西是给开发者用的看的,并且他们不熟悉你的编程接口.这个时候API的命名约定就派上用场了,因为它使你的写

说说Python编码规范

前言 已有近两个月没有发表过文章了,前段时间外甥和女儿过来这边渡暑假,平常晚上和周末时间都陪着她们了,趁这个周末有空,再抽空再把这块拾起来.         这么久没写了,再次拿起键盘,想想,发表些什么呢,想起上次公司的代码评审委员会下周其中一个议题是关于Python编码规范的整理,那就趁热打铁,整理一份关于Python编码规范的文章,也为那些写Python的人,提供一些编码注意的一些事项或者说是参考吧. 编码规范的作用         规范故明思义,就是通过不断的总结,吸取好的点,从而形成的一

Android 编码规范

编码规范对于程序员而言,尤为重要,有以下几个原因: 一个软件的生命周期中,80%的花费在于维护: 几乎没有任何一个软件,在其整个生命周期中,均由最初的开发来维护: 编码规范可以改善软件的可读性,可以让程序员尽快而彻底地理解新的代码: 如果你将源码作为产品发布,就需要确认它是否被很好的打包并且清晰无误,一如你已构建的其他任何产品: 命名 1.包命名 包名规则:一个唯一的包名的前缀总是全部小写的ASCII字母并且是一个顶级域名,如com.edu.gov.net.org等.包名的后续部分根据不同机构各

PSR : php编码规范

诸王混战 关于开发标准这块,可以说一直都是风格迥异,各家都有各家的玩法,民间更是个人玩个人的.目前我们国内比较出名的几个框架(Yii,Laravel) 都已经支持Composer并且加入了PHP-FIG(php框架程序组). 其中Composer的自动加载就支持PHP-FIG指定的PSR-0 和 PSR-4 规范来实现自动加载机制,并且Composer推荐使用PSR-4 PHP-FIG 这是一个自愿非正式的机构,但是就目前对我们的影响来看,可能都已经默认为一个公信组织了,的的确确制定了不少非常好