Go开发规范
一、编码类规范
1、命名规范
命名是代码规范中很重要的一部分，统一的命名规则有利于提高的代码的可读性，好的命名仅仅通过命名就可以获取到足够多的信息
Go在命名时以字母a到Z或a到Z或下划线开头，后面跟着零或更多的字母、下划线和数字(0到9)。Go不允许在命名时中使用@、$和%等标点符号。Go是一种区分大小写的编程语言。因此，Manpower和manpower是两个不同的命名
①：当命名（包括常量、变量、类型、函数名、结构字段等等）以一个大写字母开头，如：Group1，那么使用这种形式的标识符的对象就可以被外部包的代码所使用（客户端程序需要先导入这个包），这被称为导出（像面向对象语言中的 public）；
②：命名如果以小写字母开头，则对包外是不可见的，但是他们在整个包的内部是可见并且可用的（像面向对象语言中的 private ）
①：包命名
- 包名必须和目录名一致，尽量采取有意义、简短的包名，不要和标准库冲突
- 包名全部为小写单词，不要使用下划线或者混合大小写
- 使用多级目录来划分层级
- 项目名可以通过中划线来连接多个单词
- 包名以及包所在的目录名，不要使用复数，比如 net/utl 而不是 net/urls
- 不要用 common、util、shared 或者 lib 这类宽泛的、无意义的包名，包名要简单明了，例如 net、time、log
package demo package main
②：函数
- 函数名采用驼峰式，首字母根据访问控制决定使用大写或小写
③：结构体
- 采用驼峰命名方式，首字母根据访问控制决定使用大写或小写
- 结构体名不应该是动词，应该是名词
- 避免使用 Data、Info 这类无意义的结构体名
- 结构体的声明和初始化应采用多行
// User 多行声明 type User struct { Name string Email string } // 多行初始化 u := User{ UserName: "hello", Email: "hello@123.com", }
④：接口（基本和结构体命名规则保持一致）
- 单个函数的接口名以 “er””作为后缀（例如 Reader，Writer），有时候可能导致蹩脚的英文，但是没关系
- 两个函数的接口名以两个函数名命名，例如 ReadWriter
- 三个以上函数的接口名，类似于结构体名
⑤：变量
- 变量名必须遵循驼峰式，首字母根据访问控制决定使用大写或小写
- 在相对简单（对象数量少、针对性强）的环境中，可以将一些名称由完整单词简写为单个字母，比如：user 可简写为 u；userID 可简写 uid
- 对于私有特有名词为首个单词则使用小写（如 apiClient）。其他特有名词都应当使用该名词原有的写法，如 APIClient、repoID、UserID
- 若变量类型为 bool 类型，则名称应以 Has，Is，Can 或 Allow 开头
- 局部变量应当尽可能短小，比如使用 buf 指代 buffer，使用 i 指代 index
⑥：常量
常量均需使用全部大写字母组成，并使用下划线分词，const APP_VER = "1.0"
如果是枚举类型的常量，需要先创建相应类型：
type Scheme string
const (
HTTP Scheme = "http"
HTTPS Scheme = "https"
)⑦：Error
- Error 类型应该写成 FooError 的形式，比如 type ExitError struct {}
- Error 变量写成 ErrFoo 的形式，比如 var ErrFormat = errors.New("unknown format")
⑦：文件
- 文件名要简短有意义，应小写并使用下划线分割单词
二、非编码类规范
1、目录结构
Go社区比较推荐的目录结构：https://github.com/golang-standards/project-layout/blob/master/README_zh.md
├── api # 当前项目对外提供的各种不同类型的 API 接口定义文件
│ ├── openapi
| ├── protobuf-spec
| ├── thrift-spec
| ├── http-spec
│ └── swagger
| ├── docs/
| ├── README.md
│ └── swagger.yaml
├── assets # 项目的其他资源 (图片、CSS、JavaScript 等）
├── build # 安装包和持续集成相关的文件
│ ├── ci # CI（travis，circle，drone）的配置文件和脚本
│ ├── docker # 子项目各个组件的 Dockerfile 文件
│ │ ├── iam-apiserver
│ │ ├── iam-authz-server
│ │ └── iam-pump
│ └── package # 容器（Docker）、系统（deb, rpm, pkg）的包配置和脚本
├── CHANGELOG # 更新记录，方便了解当前版本的更新内容或者历史更新内容
| # 可结合 Angular 规范 和 git-chglog 来自动生成
├── cmd # 统一存放组件 main 函数所在目录，不存放过多代码
| | # 其下的目录名与可执行文件名一致
│ ├── iam-apiserver
│ │ └── apiserver.go
│ ├── iam-authz-server
│ │ └── authzserver.go
│ ├── iamctl
│ │ └── iamctl.go
│ └── iam-pump
│ └── pump.go
├── configs # 配置文件模板或默认配置，不携带敏感信息（占位符替代）
├── CONTRIBUTING.md # 说明如何贡献代码，如何开源协同等
| # 用于规范协同流程、降低第三方开发者贡献代码的难度
├── deploy # Iaas、PaaS 系统和容器编排部署配置和模板
├── docs # 设计文档、开发文档和用户文档等（除了 godoc 生成的文档）
│ ├── devel # 开发文档、hack 文档等
│ │ ├── en-US
│ │ └── zh-CN
│ ├── guide # 用户手册，安装、quickstart、产品文档等
│ │ ├── en-US
│ │ └── zh-CN
│ ├── images # 图片文件
│ └── README.md
├── examples # 应用程序或者公共包的示例代码
├── githooks
├── go.mod
├── go.sum
├── init # 初始化系统（systemd，upstart，sysv）、进程管理配置文件（runit，supervisord）
├── internal # 私有应用和库代码，在被尝试引入时编译会报错
│ ├── apiserver # 应用目录，包含应用程序实现代码。
│ │ ├── c
│ │ │ └── v1 # HTTP API 具体实现，实现请求解包、参数校验、业务逻辑处理、返回。
| | | | # 业务逻辑较轻，复杂的建议放到 /internal/apiserver/service 下
│ │ │ └── user
│ │ ├── apiserver.go
│ │ ├── options
│ │ ├── service
│ │ ├── store # 与数据库交互、持久化代码
│ │ │ ├── mysql
│ │ │ └── fake
│ │ └── testing
│ ├── iamctl # 客户端工具
│ │ ├── cmd
│ │ │ ├── completion
│ │ │ └── user
│ │ └── util
│ └── pkg # 项目内可共享，项目外不共享的包
| | # 准备对外开发时再转存到 /pkg
│ ├── code # 项目业务 Code 码
│ ├── options
│ ├── server
│ ├── util
| ├── middleware # HTTP 请求处理链
│ └── validation # 通用的验证函数
├── LICENSE # 版权文件，可以是私有或开源
├── Makefile # 执行静态代码检查、单元测试、编译等功能
| # gen -> format -> lint -> test -> build
├── _output # 编译输出的二进制文件
│ └── platforms
│ └── linux
│ └── amd64
├── pkg # 可被外部应用使用的代码（import），需要慎重
│ └── util
│ └── genutil
├── README.md # 项目介绍、功能、快速安装和使用指引、详细文档链接、开发指引等
├── scripts # 脚本文件，实现构建、安装、分析等不同功能
│ ├── lib # 执行自动化任务 shell 的脚本，发布、更新文档、生成代码等
| | ├── util.sh
| | └── logging.sh
| ├── install # 复杂的自动化部署脚本
│ └── make-rules # 实现 /Makefile 文件中的各个功能
├── test # 其他外部测试应用和测试数据
│ └── data # 需要 Go 忽略该目录中的内容时使用
├── third_party # 外部帮助工具，分支代码或其他第三方应用，比如 Swagger
│ └── forked # fork 并作改动的第三方包，便于与 upstream 同步
├── tools # 项目的支持工具。可导入来自 /pkg 和 /internal 的代码
├── vendor # 项目依赖，可通过 go mod vendor 创建
| # 对于 Go 库不要提交 vendor 依赖包
├── website # 如不使用 GitHub 页面，可在此放置项目网站相关的数据
└── web # 前端代码，主要是静态资源，服务端模板和单页应用（SPAs）
小型项目：
tms
├── cmd
├── internal
├── pkg
└── README.md
附录：
uber go 代码规范： https://tonybai.com/2019/10/12/uber-go-style-guide/
Go 语言高性能编程 https://geektutu.com/post/high-performance-go.html
https://zhuanlan.zhihu.com/p/63250689
END.
