公司内部的 Go 代码规范中限制了每一行代码的宽度。为了满足这个规范，那些太宽的代码行就不可避免地需要换行。换行不是普通的回车就行，如何在换行的同时，保持代码优秀的可读性，笔者根据日常 code review 中看到的各种模式，提出一些建议。

公司的 Go 规范统一要求每一行 Go 代码不能超过 120 个可显示字符的宽度。为什么要限制呢？在 这篇文章 中的描述我是非常赞同的，这里笔者就不再赘述了，读者可以直接参阅。

至于 120 这个数字是怎么来的？我就非常费解了。或许是觉得 80 是在太短，而 160 又太长，所以就取了一个折中值吧。

好，那么既然换行是不可避免的，那么接下来就是要如何换行了。下面笔者针对一些有争议的代码超宽换行的情况，具体说明如何优雅地换行。

实际上，除了一些例外情况，那么需要换行的地方，比较有争议的主要都是集中在函数签名 / 函数调用上。

下面我举一个例子，比如说我们要定义一个函数，包含以下信息：

根据上述信息，我们设计一个接口，信息如下：

不要吐槽命名太长, 这里是为了示例。此外，这也很可能是一个 protobuf 生成的 interface，那么按照很多团队的 pb 明明习惯，确实入参和出参的明明也是非常的长。

OK，如果咱们不换行，这个函数就是这个样子的：

上面的这个代码段，你的浏览器上出现了横滚动条了吗？

OK，咱们要对上面的函数换行了。其实换行的方式呢，其实有很多流派。这里我列出几种我在 code review 中见过的几种流派（不同流派可以有交叉）：

这种模式中，就是按照逗号换行。允许部分入参和函数名放在同一行中。

其实单纯地允许部分入参换行，那感觉很明显地是为了满足代码规范而应试，这是会被诟病的地方，因此，这个流派中，往往会有一个限制，就是 “只有 context.Context” 类型允许与函数放在同一行。

这么主张的同学，理由是认为 ctx 是许多函数 / 方法所需的默认参数，它也并不是一个关键的入参，因此把它和函数名凑在一起并不会影响整个函数的可读性。

这种模式中，入参和出参是允许放在同一行的。

这种流派有一个问题，就是函数签名的部分和函数实现正文处于同一锁进，那么当代码密度很高的时候，一眼区分不出函数签名和正文的分水岭。

其实使用这种模式的同学，很多只是纯纯地不喜欢下面的流派 3 而已

这个流派的重点是：入参和出参不允许放在一行，但是入参的换行比较自由，或者说缺乏统一的指导规范，而这一缺乏规范就是为其他流派所诟病的点，认为这对可读性不佳。

此外前面不是提到流派 2 不喜欢流派 3 嘛，其中一个理由是不喜欢出入参换行以后出现的一个零锁进，认为这破坏了代码块的层级。

这个流派的点呢，则是认为每一个入参都应该独立为一行。这主要是针对 3 的诟病点，认为既然参数如何换行缺乏规范，那么干脆我们就全部换行好了。

这个流派从规范角度，是足以满足的。大部分情况下，也不会出现函数签名过高的情况，以为我们还有另外一个规范：入参不得超过5个，因此这里入参最多盖 5 层楼。

不过呢这个流派被攻击的点也就是这个盖楼，特别是当入参类型名非常短的时候，就特别地难看。

可能有同学会提问：怎么上面的流派都是入参，没有出参？诚然，我们的规范是要求出参不得超过 3 个，这往往会有两种情况：

综上，出参都顺利放在同一行内，没有出现需要换行的情况。

不知道读者看了之后还有什么想法（欢迎在评论区告诉我）。诚然，每种流派都有自己的优缺点和道理。各团队可以根据各自的团队习惯制定一个指导。笔者个人使用的基本上是流派 3，但是针对入参应该如何换行的问题，笔者秉承以下原则：

按照我的这个原则，上面的函数可以写成：

上述的流派是针对函数签名的，对于函数调用，换行流派也是类似的，不过还多了一个流派争议：

这里我举一个例子，日志：

最后一个参数不换行的话，就是这个样子的：

如果换行的话：

不换行派的拥趸认为换行是脱裤子放屁，而换行派的支持者则认为这完成了一个完整的代码块锁进，清晰地指明了一行代码的开始与结束。

笔者是换行派，函数调用中必然换行。因此，笔者不喜欢长长的链式调用，因为这种模式破坏了代码块的层级。（这也是笔者不喜欢 gorm 的原因之一）

虽然规范中对代码宽度进行了限制，但是实际上在一些情况下，由于 Go 语言语法的限制会导致换行后语法就不通过的情况，或者是不建议换行的情况：

本文章采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。

原作者： amc，欢迎转载，但请注明出处。

原文标题：《每天学点 Go 规范 - 代码不能写太宽，那么函数该怎么换行呢？》

发布日期：2023-12-06

原文链接：https://cloud.tencent.com/developer/article/2368120。