Golangでの「this」の使用

Golangがここにあるスタイルガイドに最も近いのは、Receiver Namesの下です。

メソッドのレシーバーの名前は、そのアイデンティティを反映したものでなければなりません。多くの場合、そのタイプの1文字または2文字の略語で十分です（「クライアント」の「c」または「cl」など）。「me」、「this」、「self」などの汎用名は使用しないでください。これらは、関数ではなくメソッドに重点を置くオブジェクト指向言語の典型的な識別子です。名前はメソッドの引数のように説明的なものである必要はありません。その役割は明白であり、文書の目的には役立たないからです。

個人的には、「this」が関数の記述および編集時に取り組んでいるものの焦点であるため、常に「this」を識別子として使用しています。それは正しいように聞こえ、（少なくとも私には）理にかなっています。

名前が記述的である必要がない場合、その役割は明白であり、ドキュメンタリーの目的を果たしません。なぜ「これ」の使用が眉をひそめるのでしょうか？

そのスタイルガイドの作成者に確実に知ってもらう必要がありますが、私が彼に同意する主な理由は、構造体とメソッドの間の接続が他の言語よりもGoではるかに緩いことです。

本質的に、次のようなメソッドを記述する場合：

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

これは、次のような関数を書くこととほぼ同じです。

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

唯一の違いは、関数/メソッドの呼び出し方法のわずかな構文の変更です。

他の言語では、通常、this/ self/ whatever変数には、言語によって魔法のように提供されたり、プライベートメソッドに特別にアクセスしたりするなどの特別なプロパティがあります（Goにはプライベートフィールド/メソッドがないことに注意してください）。「レシーバー」はまだある程度「魔法のように提供」されていますが、通常の関数の引数に非常に似ているため、おそらくカウントされません。

さらに、「従来の」OOP言語では、構造体/クラスのメソッドにはすべて構造体/クラス定義が付属しているため、外部から追加することはできません。Goでは、私が知る限り、誰でも（もちろん、独自のコードの範囲内で）より多くのメソッドを追加できます。

独自のスタイルガイドを作成するのに十分なGoを記述していませんが、個人的にはthis、受信する構造体と同じファイルで定義されたメソッドで使用するでしょう。。

私はこのスタイルガイドで納得していないと私は何よりも優れているとは思わないthis、meまたはself。そのためthis、meあるいはselfそれがスーパークリアな変数は、コンテキスト構造体のインスタンスであることになります。小文字の構造体名変数が悪い考えだと言っているのではなくthis、それが非常に明確になる方法が好きです。

これはthis、コンパイラにとって実際のキーワードの意味を持つJavaScriptの観点からですが、私の理解では、オブジェクトタイプの2文字の省略形で問題なければ、代わりにそれを使用するのは十分に簡単なはずです。違いの理由は、徐々に大きくなる非同期コードのかなり大きなブロックでは、「これ」または受信者がより深いコンテキストにあるものを誤解するのは非常に簡単だからです。また、同じオブジェクトではない可能性があります。

たとえばJavaScriptでは、コントロールモジュールがダイアログを起動し、onLoadインラインで関数を宣言する場合があります。しかし、その時点では、別のコーダーがthis内部onLoadでは誤って解釈してダイアログではなく制御モジュールを参照するのは非常に簡単です。またはその逆。コントロールがと呼ばれctrl、ダイアログがと呼ばれる場合、これは回避できますdg。