在Golang中使用“ this”

对于Golang而言，最接近于此处的样式指南的东西是这样写的：

方法的接收者的名称应反映其身份。通常，其类型的一个或两个字母缩写就足够了（例如，“ Client”（客户）使用“ c”或“ cl”）。不要使用诸如“我”，“此”或“自我”之类的通用名称，它们是面向对象语言的典型标识符，这些标识符更加强调方法而非功能。该名称不必像方法参数那样具有描述性，因为它的作用是显而易见的，没有任何文档目的。

我个人一直只是使用“ this”作为标识符，因为“ this”是我编写和编辑函数时正在研究的重点。听起来不错，而且（至少对我而言）是有道理的。

如果名称不需要描述，那么它的作用是显而易见的，并且没有记录目的，为什么“ this”的使用会被拒绝？

我们必须让该样式指南的作者肯定知道，但是我认为我同意他的主要原因是Go中的struct和method之间的联系比其他语言宽松得多。

本质上，当您编写这样的方法时：

func (m *MultiShape) area() float64 {
  ...
}

这几乎与编写这样的函数完全一样：

func area(m *MultiShape) float64 {
  ...
}

唯一的区别是在调用函数/方法的方式上语法略有变化。

在其他语言中，this// selfwhatever变量通常具有一些特殊的属性，例如由语言神奇地提供，或具有对私有方法的特殊访问权限（请记住，Go没有私有字段/方法）。尽管仍在某种程度上“神奇地提供”了“接收器”，但它与常规函数自变量非常相似，可以说它不算在内。

另外，在“传统” OOP语言中，所有struct / class定义都带有struct / class方法，因此无法从外部添加更多内容。据我所知，在Go中，任何人都可以向任何事物添加更多方法（当然，在他们自己的代码范围内）。

我还没有编写足够的Go语言来编写自己的样式指南，但就我个人而言，我可能会使用this与它们接收到的结构在同一文件中定义的方法，并在我附加到其他文件的结构上的方法中使用一些更具描述性的接收器名称。

我不是这个风格指南确信，我觉得没有什么比好this，me或self。因为this，me或self使用户能够无比清晰的变量是上下文结构的一个实例。我并不是说小写的struct name变量不是一个好主意，我只是喜欢this使其变得非常清晰的方式。

从JavaScript的角度看this，它对编译器具有实际的关键字含义，但是从我的理解来看，如果它们可以使用对象类型的两个字母缩写，那么使用它应该足够容易。造成这种差异的原因是，在一个相当大的，逐步深入的异步代码块中，很容易会误解“此”或接收者在更深的上下文中的含义。并且可能不会是同一对象。

例如，在JavaScript中，控制模块可能会启动一个对话框并onLoad为其声明一个内联函数。但是到那时，另一个编码器很容易将this内部错误解释onLoad为引用控制模块，而不是对话框。或相反亦然。如果将控件称为ctrl并将对话框称为，则可以避免这种情况dg。