

首页  思维导图  详情



Go 编码规范：The Zen of Go

2021-07-16 20:50:14   0  举报





AI智能生成

Go 可维护代码建议

代码建议

模版推荐

作者其他创作

大纲/内容

标准实践

命名规范

编程规范

代码结构及执行顺序

表示执行成功/失败<br>

实用代码片段

调试程序

计算函数执行时间

字节数组对比函数

反射

reflect.TypeOf(x)

Kind()

Field(ix)

reflect.ValueOf(x)

Kind()

Type()

Interface()

Elem()

CanSet()

Field(i)

NumField()

Method(i)

布局标准实践

布局结构演化

Go 1.4 删除 pkg 引入 internal 包机制

Go1.5 增加 vendor 包机制

Go 1.11 引入 Module 构建机制

多个 module 

可执行程序布局

标准的可执行程序项目布局

早期可执行程序项目的典型布局

简化布局：只有一个可执行程序要构建

有一个且仅有一个包的 Go 库项目

仅对外暴露 Go 包布局

其他

参考布局思路 

开源项目 GoFrame

思考

工程目录

子主题

go-clean-template

指导原则

清晰

简单

生产力

标识符

好名称特征

具有描述性

具有可预测性

简洁而不是简短

实用建议

不要在变量名中包含类型的名称。

命名长度：遵循声明和使用的距离越远，名称长度越长；

包的名称是调用者用来引用它的名称的一部分，因此要利用它。

要保持一致的命名风格

要保持一致的声明风格

在声明而不是初始化变量时，使用 var。

在声明和初始化时，使用 : =

例外

团队精神

保持一致性，即使它不是你的首选方法，从长远来看，比你的个人偏好更有价值。

注释

作用

解释干什么

解释怎么做

解释为什么

一些建议

对常量和变量应该描述其内容而不是用途

不要注释错误的代码, 应该提醒重构它

与其给一段代码加注释，不如重构它

好的代码本身就是最好的文档

Google 样式指南

任何不是显而易见和简短的公共功能都必须加以注释。

库中的任何函数都必须注释，而不管其长度或复杂性如何。

例外:不需要记录实现接口的方法

包设计

好的包名

简短与清晰，应该描述其用途而不是内容

应该是唯一的

一些建议

包的名称是调用者用来引用它的名称的一部分，因此要利用它。

尽量使用单字（sigle-word）包名，如果非得使用多字包名（multiple-word）规范：直接多字连接作为包名。如：stringset, helloworld

尽量不用通用词：good: bufio，bad: buf，尽量不使用无意义的包名：util, common

可理解性的缩写：strconv（string convention）syscall，fmt，用一些比较高频易懂的词

实用工具包

尽量避免实用程序包

使用复数命名实用工具包

在许多地方使用工具函数的情况下

比起单一的整体包，更喜欢使用多个包，每个包集中在一个方面。

在较少地方使用工具函数的情况下

将相关的函数移动到调用者的包中。

为什么其他语言可以？

尽早返回而不是深入嵌套

让零值变得有用

一个令人惊讶的特性

避免包级别的状态

使用接口来描述函数或方法需要的行为

避免使用全局状态