前言: \textcolor{Green}{前言:} 前言:
💞这个专栏就专门来记录一下寒假参加的第五期字节跳动训练营
💞从这个专栏里面可以迅速获得Go的知识
本次文章不仅仅是在 go 中主要注意,在编写其他语言中也同样重要。因为我们是一个团队,主张的是团队合作,编写的代码都是给他人看的,我们编写一个好的代码会给他人带来乐感。同时在面试的时候,面试官看到你写的代码岂不是开开心心的。必须写的明明白白的,接下来就一起学习吧。
本文中还有后续等待发布,编码规范远不止这么点,我会加紧更新的。
本次学习的目标:如何编写更简洁清晰的代码
本章内容主要是讲解高质量编程包含以下三个内容
- 高质量编程简介
- 编程规范
- 性能优化建议
高质量编程
- 一、高质量编程
- 1.1 简介
- 1.2 编码规范
- 1.2.1 编码规范 - 代码格式
- 1.2.2 编码规范 - 注释
- 总结
- 参考
一、高质量编程
1.1 简介
什么是高质量:编写的代码能够达到正确可靠
、简洁清晰
的目标。
同时还需要考虑到以下情况
- 正确性:各种边界条件是否考虑完备,错误的调用是否能够处理
- 可靠性:异常情况或错误的处理策略是否明确,依赖的服务出现异常是否能够处理。保证稳定性。
- 简洁:逻辑是否简单,是否能够快速支持后续调整功能或新增功能。
- 清晰:在阅读代码的的时候能否清晰明了,重构或修改功能是否不会出现担心无法预料的问题。也就是
易读易维护
编程原则
实际应用场景是千变万化的,尤其是各种语言的特性和语法各不相同。但是高质量编程遵循的原则是相同的。这就是之前和大家说过的,之前使用java过程中也会有高质量编程的规范,所以无论世界怎么变化,原则是不变的。
注意以下几点
- 简单性
- 消除“多余的复杂性”,以简单清晰的逻辑编写代码
- 不理解的代码无法修复改进
在实际应用过程中,复杂的程序逻辑难以重构和优化。因为无法明确预知调整造成的影响范围。难以理解的逻辑,排查道德问题也很难定位,不知道如何修复。
- 可读性
- 代码是写给人看的,而不是机器。
- 编写可维护代码的第一步是确保代码可读。
在项目的迭代过程中,后续的工作是对已有功能的完善或扩展,基本上很少完全对某个功能去掉,对应的代码也会存在很长时间。所以一个代码的可读性是非常有必要,否则会占用很多人的时间。
- 生产力
- 团队整体工作效率非常重要。
我们作为程序猿相信对这个已经不陌生了,讲究的是团队合作,讲究一个工作效率。在 GO 中为了降低新手的上手 Go 的成本,GO 还通过工具强制统一所有代码格式。
整体的编码,所有人遵循规范,可以避免常见缺陷的代码,降低后续测试、验证、上线等各个节点出现的概率,即使出现问题,也可以快速排查定位。
1.2 编码规范
如何编写高质量的 Go 代码
- 代码格式
- 注释
- 命名规范
- 控制流程
- 错误和异常处理
1.2.1 编码规范 - 代码格式
- 推荐使用 gofmt 自动格式化代码
- 要保证所有的 go 代码与官方推荐格式保持一致。
- gofmt 是 go 语言官方提供的工具,能自动格式化 go 语言代码为官方统一风格。
- 很方便进行配置,像 Golang 内置了相关功能,直接开启就可以在保存文件的时候自动格式化了。常见的 IDE 都支持方便的配置。
- goimports
- 这也是 Go 语言官方提供的工具。
- 这个也会对依赖包进行管理,实际等于 gofmt 加上依赖包管理。
- 自动增删依赖的包引用,将依赖包按字母排序分类,具体情况下具体分析。
1.2.2 编码规范 - 注释
我们不能只关注代码实现,还需要关注注释,这个是非常重要的,也是容易忽视的。
简介
- 注释应该遵循以下四点
- 注释应该解释代码作用
- 注释应该解释代码如何做的
- 注释应该解释代码实现的原因
- 注释应该解释代码什么情况会出错
接下来引用一句话
Good code has lots of comments, bad code requires lots of comments
好的代码有很多注释,坏代码需要很多注释 ---- Dave Thomas and Andrew Hunt
1.注释应该解释代码作用
注释应该解释代码作用
- 适合注释公共符号:例如对外提供的函数注释描述它的功能和用途,只有在函数的功能简单而明显时才能省略这些注释(例如:简单的取值和设值)。
另外注释要避免啰嗦,不要对显而易见的内容进行说明,有些可以通过名称就知道内容。
Go 仓库
github连接
像第一白框中的注释显得就多了,没有必要。
注释应该解释代码如何做的
- 适合注释实现过程
第二种注释是对代码中复杂的,并不明显的逻辑进行说明,适时注释实现过程。
上面的代码是给新 URL 加上最近的 refer 信息,并不是很明显,所以需要注释说明。
下面的例子是不正确的:虽然对过程进行了注释,但是描述的是显而易见的流程,不要用自然语言直接翻译代码作为注释
,信息冗余,有时候表述不一定和代码一致。
注释应该解释代码实现的原因
- 适合解释代码的外部因素。(这些因素脱离上下文后是很难理解的)
- 提供额外的上下文
图中可以看到: shouldRedirect = false
。如果没有对其进行注释,很难明白为什么要设置 false;
注释应该解释代码什么情况下会出错
- 适合解释代码的限制条件或者无法处理的情况
例如图中函数的注释说明是否存在性能隐藏,输入的限制条件,可能存在哪些错误情况,让使用者无需了解实现细节。同时也介绍了了解时区字符串的流程,同时对可能遇到的不规范字符串处理进行了说明。
公共符号始终要注释
-
包中声明的每个公共的符号:变量、常量、函数以及结构都需要添加注释。
-
任何既不明显也不简短的公共功能必须予以注释
-
无论长度或复杂程度如何,对库中任何函数都必须进行注释。
上图中的注释结合之前的注释,表述了函数的功能和如何工作。 -
有一个例外,不需要注释实现接口的方法。
- 例如图中的注释没有告诉你这个方法做了什么什么,甚至让你去看其他文档,这种情况建议删除。
- 例如图中的注释没有告诉你这个方法做了什么什么,甚至让你去看其他文档,这种情况建议删除。
- 对于公共符号都有注释说明
- 尽管 LimitedReader.Read 本身没有注释,但它紧跟 LimitedReader 结构的声明,明确它的作用。
总结
- 代码是最好的注释
- 注释应该提供代码未表达出的上下文信息
参考
高质量编程简介及编码规范