Go 编码规范：The Zen of Go
2021-07-16 20:50:14 0 举报AI智能生成
Go 可维护代码建议
作者其他创作
大纲/内容
命名规范
编程规范
代码结构及执行顺序
表示执行成功/失败
标准实践
调试程序
计算函数执行时间
字节数组对比函数
Kind()
Field(ix)
reflect.TypeOf(x)
Type()
Interface()
Elem()
CanSet()
Field(i)
NumField()
Method(i)
reflect.ValueOf(x)
反射
实用代码片段
Go 1.4 删除 pkg 引入 internal 包机制
Go1.5 增加 vendor 包机制
多个 module
Go 1.11 引入 Module 构建机制
布局结构演化
早期可执行程序项目的典型布局
标准的可执行程序项目布局
有一个且仅有一个包的 Go 库项目
简化布局：只有一个可执行程序要构建
可执行程序布局
仅对外暴露 Go 包 布局
参考布局思路
思考
工程目录
子主题
开源项目 GoFrame
go-clean-template
其他
布局标准实践
清晰
简单
生产力
指导原则
可读性
实用性
可靠性
具有描述性
具有可预测性
简洁而不是简短
好名称特征
不要在变量名中包含类型的名称。
命名长度：遵循声明和使用的距离越远，名称长度越长；
包的名称是调用者用来引用它的名称的一部分，因此要利用它。
要保持一致的命名风格
在声明而不是初始化变量时，使用 var。
在声明和初始化时，使用 : =
例外
要保持一致的声明风格
保持一致性，即使它不是你的首选方法，从长远来看，比你的个人偏好更有价值。
团队精神
实用建议
标识符
解释干什么
解释怎么做
解释为什么
作用
只能做其中之一
对常量和变量应该描述其内容而不是用途
与其给一段代码加注释，不如重构它
好的代码本身就是最好的文档
任何不是显而易见和简短的公共功能都必须加以注释。
库中的任何函数都必须注释，而不管其长度或复杂性如何。
例外:不需要记录实现接口的方法
Google 样式指南
一些建议
注释
简短与清晰，应该描述其用途而不是内容
应该是唯一的
好的包名
可理解性的缩写：strconv（string convention）syscall，fmt，用一些比较高频易懂的词
尽量避免实用程序包
使用复数命名实用工具包
比起单一的整体包，更喜欢使用多个包，每个包集中在一个方面。
在许多地方使用工具函数的情况下
将相关的函数移动到调用者的包中。
在较少地方使用工具函数的情况下
为什么其他语言可以？
实用工具包
尽早返回而不是深入嵌套
一个令人惊讶的特性
让零值变得有用
使用接口来描述函数或方法需要的行为
避免使用全局状态
避免包级别的状态
包设计
Practical Go: Real world advice for writing maintainable Go programs
官方代码规范指南 Go Code Review Comments
翻译版
Uber Go Style Guide
如何写出优雅的 Golang 代码
推荐
Go 可维护代码建议
0 条评论
回复 删除
下一页
