高质量编程简介和异常处理 | 青训营笔记

CN千石
178 阅读8分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 2 天

高质量编程简介和异常处理

前排提示：文章内容较多，如需上下文对照阅读，请善用CTRL+F和目录功能

前言

前置知识

阅读本文内容，你可能需要以下基础知识

  • Go 语言基础
  • 如何用 Go 编写程序

课程重点知识

阅读本文，你可以收获以下内容：

  • 如何编写更简洁清晰的代码
  • 常用 Go语言程序优化手段
  • 熟悉 Go 程序性能分析工具
  • 了解工程中性能优化的原则和流程

正文

什么是高质量编程？

编写的代码能够达到正确可靠、简洁清晰的目标可称之为高质量代码

  • 正确性：实现功能时，是否考虑到各种边界条件？服务出现异常情况是否能正确处理？是否有明确的应对策略？
  • 简洁清晰：在团队协作中，代码是写给团队成员看的，我们的代码应该易读易维护
    • 简洁：让代码逻辑尽可能简单，后续调整功能时能更快的能更快评估修改的影响
    • 清晰：让别人阅读代码能清楚的明白代码的含义和作用

编程原则

实际应用场景千变万化，各种语言的特性和语法各不相同，但是高质量编程遵循的原则上相通的

简单性

  • 目的：消除“多余的复杂性”，以简单清晰的逻辑编写代码
  • 不理解的代码无法修复改进

可读性

  • 代码是写给人看的，而不是机器
  • 编写和维护代码的第一步是确保代码可读

生产力

  • 团队整体工作效率非常重要

遵循编程原则的优点

  • 易于维护和扩展：
    • 使代码更加清晰，易于理解和修改。
  • 易于重用：
    • 使代码更加结构化，易于重用。
  • 更高的可读性：
    • 使代码更加易读，方便其他人阅读和理解。
  • 更少的错误：
    • 使代码更加严谨，减少错误的可能性。
  • 更高的生产力：
    • 使开发人员更加高效。

编码规范

注释

Good code has lots of comments, bad code requires lots of comments

好的代码有很多注释，坏代码需要很多注释

简介

  • 注释应该解释代码的作用
    • 这样，阅读代码的人就可以很快地了解代码所做的事情。
  • 注释应该解释代码如何做的
    • 这样，阅读代码的人就可以理解代码如何实现其功能。
  • 注释应该解释代码实现的原因
    • 这样，阅读代码的人就可以了解为什么要这样实现，是否有其他选择。
  • 注释应该解释代码什么情况会出错
    • 这样，阅读代码的人就可以了解代码在什么情况下会出错，以及如何避免这种情况。

注释应该解释代码的作用

  • 适合注释公共符号

注释应该解释代码如何做的

  • 适合注释实现过程

注释应该解释代码实现的原因

  • 适合解释代码的外部因素
  • 提供额外的上下文

注释应该解释代码什么情况会出错

  • 适合解释代码的限制条件

公共符号始终要注释

  • 对于公共符号都有注释说明
  • 尽管LimitedReader.Read本身没有注释，但它紧跟 LimitedReader 结构的声明，明确它的作用

小结

  • 代码是最好的注释

  • 注释应该提供代码未表达出的上下文信息

    既不明显也不简短的公共功能必须予以注释 无论方法的长度或者复杂度，对于库中公开的函数也必须予以注释

eg：下面这一段代码是对外提供的，所以需要对函数的功能和函数如何工作进行注释说明

func ReadAll(r Reader) ([]byte, error)

例外：注释是为了提供额外的上下文信息，不需要注释实现接口的方法

代码格式

推荐使用 gofmt 自动格式化代码

gofmt：一个用来格式化 Go 代码的工具。它会把代码转化为统一的格式，使代码更易读。它主要用来保证代码风格的统一。

goimports：一个用来管理 Go 代码依赖的工具。它会自动在 Go 代码中导入或删除未使用的包，使得代码更整洁。它还会根据代码需要自动添加或删除 import 语句。

命名规范

Good naming is like a good joke. If you have to explain it,it's not funny

好的命名就像是一个好笑话。如果你必须解释它，那就不好笑了

variable

  • 简洁胜于冗长
  • 缩写词全大写，但当其位于变量开头且不需要导出时，使用全小写
    • 例如使用 ServerHTTP 而不是ServerHttp
    • 使用 XMLHTTPRequest 或者 xmlHTTPRequest
  • 变量距离其被使用的地方越远，则需要携带越多的上下文信息
    • 全局变量在其名字中需要更多的上下文信息，使得在不同的地方可以轻易辨认出其含义 eg1：
// Bad
for index := 0; index < len(s); index++ {
    // do something
}

// Good
for i := 0; i < len(s); i++ {
    // do something
}

i 和 index 的作用域范围仅限于 for 循环内部时 index 的额外冗长几乎没有增加对于程序的理解

eg2：

// Bad
func (c *Client) send(req *Request, t time.Time)

// Good
func (c * Client) send(req *Request, deadline time.Time)
  • 将 deadline 替换成 t 降低了变量名的信息量
  • t 常代指任意时间
  • deadline 指截止时间，有特定的含义

function

  • 函数名不携带包名的上下文信息 ——> 包名和函数名总是成对出现的
  • 函数名尽量简短
  • 当名为 foo 的包某个函数返回类型 Foo时，可以省略类型信息而不导致歧义
  • 当名为 foo 的包某个函数返回类型 T 时（T 并不是 Foo），可以在函数名中加入类型信息

http包中创建服务的函数如何命名更好？

不必添加额外的上下文，利用好自身的上下文信息

package

  • 只由小写字母组成，不包含大小写字母和下划线等
  • 简短并包含一定的上下文信息
  • 不与标准名同名

尽量满足

  • 不使用常用变量名作为包名
  • 使用单数而不是复数
  • 谨慎的使用缩写

小结

  • 核心目标是降低阅读理解代码的成本
  • 重点考虑上下文信息，设计简洁清晰的名称

控制流程

避免嵌套，保持正常流程清晰

  • 如果两个分支中都包含return语句，则可以去除冗余的else

尽量保持正常代码路径为最小缩进

  • 优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套

小结

  • 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
  • 正常流程代码沿着屏幕向下移动
  • 提升代码可维护性和可读性
  • 故障问题大多出现在复杂的条件语句和循环语句中

错误和异常处理

简单错误

  • 定义：仅出现一次，且在其他地方不需要捕获该错误
  • 优先使用 error.New 来创建匿名变量来直接表示简单错误
  • 如果有格式化的需求，使用fmt.Errorf

错误的 Wrap 和 Unwrap

  • 错误的 Wrap 实际上是提供了一个 error 嵌套另一个 error 的能力，从而生成一个 error 的跟踪链
  • 在 fmt.Errorf 中使用：%w 关键字来讲一个错误关联至错误链中

错误判定

  • 判定一个错误是否为特定错误，使用errors.Is
    • 不同于使用 == ，使用该方法可以判定错误链上的所有错误是否含有特定的错误
  • 在错误链上获取特定种类的错误，使用errors.As

panic

  • 不建议在业务代码中使用panic
  • 调用函数不包含 recover 会造成程序崩溃
  • 若问题可以被屏蔽或解决，建议使用 error 代替 panic
  • 当程序启动阶段发生不可逆转的错误时，可以在 init 或main 函数中使用 panic

recover

  • recover 只能在被 defer 的函数中使用
  • 嵌套不发生效
  • 只在当前的 goroutine 生效
  • defer 的语句是后进先出
  • 如果需要更多的上下文信息，可以 recover 后在 log 中记录当前的调用栈

小结

  • error 尽可能提供简洁明了的上下文信息链，方便定位问题
  • panic 用于真正异常的情况
  • recover 生效范围，在当前 goroutine 的被 defer 的函数中生效

实战

哪种命名方式更好？

代码1

package time
func Now() Time // Better
// or
func NowTime() Time // Bad

实际调用的时候，包名是一致的，所以不需要额外的上下文

t := time.Now() // Better
t := time.NowTime() // Bad

代码2

package time
func Parse(s string) (Duration, error) // Bad
// or
func ParseDuration(s string) (Duration, error) // Better

实际调用的时候，返回的类型和time包不一样，使用会有误解

duration := time.Parse(s) // Bad
duration := time.ParseDuration(s) // Better

程序的输出是什么？

代码

func main(){
    if true {
        defer fmt.Printf("1")
    } else {
        defer fmt.Printf("2")
    }
    defer fmt.Printf("3")
}

输出：

31
  • defer 语句会在函数返回前调用
  • 多个defer语句是后进先出

总结

高质量编程是编程中非常重要的一部分，它包括遵循编程原则和遵循编程规范。编程原则可以帮助我们更好地设计和编写代码，而编程规范可以帮助团队更好地协作，提高代码的可读性和可维护性。文章中涉及了编码规范的一些具体方面，包括注释、代码格式、命名规范、控制流程和错误异常处理。

从我的角度来看，作为一名学生，我认为高质量编程是一种重要的编程技能，为了更好地掌握编码规范，建议在实际项目中使用它们，阅读其他人的代码，如果有任何疑问，不妨请教老师或者更有经验的程序员。

avatar
文章
阅读
粉丝