2

大家好,我是煎鱼。

在任何语言进行编程开发时,只要涉及到多人协作。就一定会遇到一个旷世斗争的大问题。那就是:编码风格。

Go 的,PHP 的,Java 的,C++ 的;初级、中级、高级、管理的风格;传统的、互联网的又都不一样。

谁的风格更好

例如经典的判断场景:if err != nil ,至少可以写出三种模式。如下代码:

# 方式一
if err != nil {
  // do something...
}

# 方式二
if err != nil
{
  // do something...
}

# 方式三
if err != nil { // do something... }

在团队中,到底选用哪一种方式呢?看性能?看风格?看少打几个空格?看谁拳头大?

这是个经常明的暗里撕逼的问题。

统一编码风格

在 Go 的谚语中有一句是:“Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite”。大致的意思是 Gofmt 的风格没有人喜欢,但 Gofmt 是每个人的最爱。

这是为什么呢?又爱又不爱的。

我们先从 Gofmt 的功能来讲,它能够格式化 Go 程序,使用制表符来缩进,使用空格来对齐,能够让你的代码长的都一样。

无论是谁,怎么写。只要结合 IDE 和 Gofmt 一配置,都会变成如下格式:

if err != nil {
  // do something...
}

因此在 Go 中,编码风格的争议变得毫无意义。由官方统一管控,若有矛盾也会转移到 Go 团队本身。

综合来看,大家还是会更倾向于往官方定义的风格去靠近,去符合标准,能够减少非常多的争端。

这就是为什么 ”Gofmt 是每个人的最爱“ 的原因了,当然。我认为叫 ”团队的最爱“ 可能更加的适合。

没有施展空间

谚语里也提到了,Gofmt 的风格没有人喜欢。这又怎么说?

真实的社区朋友会遇到这类场景。如下图:

来自鱼粉的微信咨询

来自鱼粉的微信咨询

实际上 Gofmt 有不少对齐有的小伙伴并不喜欢,想改。很可惜...并不能,Go 就是要完全保持一致。

甚至有同学在社区 issues 提过,Go 核心团队的 rsc 也给出了明确的直接回复:

对于 Go 的设计来讲,Gofmt 没有配置是非常重要的。如果想要增加可配置的规范化,这是不可能的。

谚语说到 Gofmt 没有人喜欢,也是因为它是一个强制性的东西,不关乎你的喜好与否,总有人喜欢不一样的规范格式。

总结

Go 编程规范的标准统一化,从不同的角度来看有好有坏。但当你接受一个历史新代码,它的编码格式都被 Gofmt 处理的整整齐齐,和你 10 年后看到的代码格式依然一致,那也确实是一个很不错的益处。

语言本身来看,它是让 Go 成功的重要原因之一,让许多团队许多人减少了很多争端,功大于过,有相当的存在必要。你认为呢?

文章持续更新,可以微信搜【脑子进煎鱼了】阅读,本文 GitHub github.com/eddycjy/blog 已收录,学习 Go 语言可以看 Go 学习地图和路线,欢迎 Star 催更。

Go 图书系列

推荐阅读


煎鱼
8.3k 声望12.8k 粉丝