Go's gofmt和diff/VCS的问题？

Question

我有一个关于Go的gofmt工具的问题，它根据官方的Go规范自动格式化程序的输出(例如，您不能争论方括号应该放在哪里，因为这显然是由规范解决的)。

在下一页：

http://golang.org/doc/effective_go.html

在“格式化”一段中，写明：

以

为例，没有必要花时间在结构的字段上排列注释。政府会为你这么做的。考虑到声明

type T struct {
    name string // name of the object
    value int // its value
}

gofmt将对列进行排列：

type T struct {
    name    string // name of the object
    value   int    // its value
}

不过，我不明白这怎么可能对diff和VCSes有好处。

例如，如果我有一个新行：

confuzzabler int // doo doo be doo

做个差别化，我应该得到这个：

2d1
<     confuzzabler int // doo doo be doo
7d5
< 

生活将是美好的:差异显示出唯一的变化。

然而，如果我重新运行政府，我得到了这个：

type T struct {
    confuzzabler int    // doo doo be doo
    name         string // name of the object
    value        int    // its value
}

现在我重新运行diff，我得到了这个：

2,4c2,3
<     confuzzabler int    // doo doo be doo
<     name         string // name of the object
<     value        int    // its value
---
>     name    string // name of the object
>     value   int    // its value
7d5
< 

这是一个非常令人困惑和误导的差异输出，因为只有一行更改。

作为一个Go开发人员，您如何处理这个问题？

Answer 1

$ diff --help|grep -i white
  -b  --ignore-space-change  Ignore changes in the amount of white space.
  -w  --ignore-all-space  Ignore all white space.

至于VCS方面的问题，如果您是按照一些既定的约定来格式化代码(让我们在这里假设这个约定是gofmt遵循的)，那么您应该按照gofmt的方式手动调整代码块中的空白格式，并且任何VCS都会将此更改计算为更改。所以我认为在这个例子中语义没有任何问题，真的。如果您关心的是VCSes提供的不同工具，那么您可能应该看看它们是否支持忽略上面提到的GNU所做的空白更改。FWIW git diff使用相同的-b命令行选项支持这一点。

Answer 2

基于围棋的项目标准应该规定如下：

在将任何Go代码提交给VCS之前，

都是用gofmt格式化的。这是唯一可以接受的格式。

然后没有任何参数；如果代码不改变地通过gofmt，那么一切都很好。如果它在通过gofmt时发生变化，则使用来自gofmt的输出。编辑过程中所做的工作取决于您自己(受其他编码标准的约束)，但这是任何签入VCS的代码的要求。

Answer 3

如果这真的困扰到你，做两次检查。

第一个签入添加了confuzzabler。一个合理的评论是“给T添加新变量”。您的差异将与您实际更改的代码隔离开来。

那就表演吧。

第二个提交只是格式化更改，一个合理的提交msg将是"gofmt“。这里的差异将仅仅是gofmt已经更改的代码。